Thank you Lars.

Your post filled in some gaps I had about how the Java option would worked.
In addition, your reference to DCE led me to some good documentation on
threads at HP.COM.  May I ask what might seem like some basic questions?  If
I configure Apache to spawn several son processes to repsond to http
requests (therefore I am in 'multi-process' land instead of 'multi-thread'
land), and I have a FASTCGI module doing the processing to generate the
response to each son-process, am I better or worse off, performance-wise,
than using a Java servlet to respond to each son-process?  In the latter
scenario, wouldn't I being using both multi-processing of Apache sons and
multi-threading of the servlet?  What does that really buy me?  Has you
indicated, with Java you would probably end up 'forking' to a routine
written in TRANSACT or some other program that interfaces easily to IMAGE.
Does this become a matter of pick your poison?  My hesitation comes from a
feeling that I am missing some obvious fact due to my lack of knowledge in
the subject.

Thanks again for everyones thoughts.

Jim McIntosh
[log in to unmask]

Lars Appel <[log in to unmask]> wrote in message
news:399c6f62_1@skycache-news.fidnet.com...
> >I am still missing a big piece in my understanding.  Can anyone point to
a
> >good resource that can explain the difference between multi-processing
and
> >multi-threading?
>
> Well, the Java VM and language offers multi-threading. The current Java/iX
> implementation uses the green-thread model, where a single process
switches
> between the different threads of execution "on top of the OS". This means
> that the application can handle multiple "tasks" at the same time, e.g.
one
> thread for each current http client connection. The next Java VM for
MPE/iX
> will be HotSpot (as far as I understand) and use Posix Threads. This will
> result in a setup similar to separate processes, where each can be
executed
> by a different CPU. Green threads, a single process, won't benefit from a
> multi-CPU machine, whereas Posix Threads will.
>
> However, even with the current green threads implementation in Java/iX,
you
> could still have each thread create an "associated" child process (via
fork
> or CREATEPROCESS) to do "hard work" like direct Image transactions in
COBOL
> or Transact or Pascal or ... and thus gain better scaling on
multi-processor
> systems. This approach might even be better than the Posix Thread approach
> in some cases, because not all of the MPE subsystems might be thread-safe.
>
> You can probably find some multi-threading/multi-processing info in the
DCE
> documentation, as this is currently the only thread library for MPE/iX
that
> I am aware of. However, at HP World, you might visit Bill Cadier's talk on
> the upcoming Posix Threads to get quite some add'l insight.
>
> (PS... One reason why I like Java and Java Servlets is that it does
provide
> infrastructure for handling a thread pool... you simply declare your
servlet
> as "implements SingleThreadModel" and the servlet engine will maintain a
pool
> of objects in such a way that none is executed by more than one thread at
a
> time... By letting each object open a JDBC connection to a database, you
can
> have database connection pooling with minimum programming effort, too).
>