JMS does deal with transaction and security propagation, though without
any interoperability (meaning, my JMS server cannot send a message to
your JMS server).
But JMS deals with asynchronous invocation, whereas threads deals with
asynchronous processing without the overhead of sending messages all day
long (= more code to write, more code to debug, more CPU time to waste),
and with the ability to interact with a process in progress.
If you send a JMS message you might be able to start a process and get a
response when it's done in an asynchronous manner, but you cannot
interfere with a running process, since you have no mechanism for a
running process (i.e. threads).
arkin
Dan OConnor wrote:
>
> It seems to me at first glance that it might be possible to map all
> the thread operations to equivalent message queue operations,
> making them logically equivalent. What are the tricky points?
> Propogation of security and transaction contexts might be two
> candidates--I don't know enough about the plumbing to know. Any
> others?
>
> Since JMS seems to be the answer whenever threads are the
> question, advocates for a threading API might want to point out
> specifically where JMS fails to provide the equivalent logical
> operations.
>
> -Dan
>
> On 5 Mar 00, at 22:56, Rickard �berg wrote:
>
> > On Sun, 5 Mar 2000 19:44:16 -0500, Charlie Alfred <[EMAIL PROTECTED]> wrote:
> > >One example of this type would be a service to find airline reservations
> > >(or hotels, car rentals, etc.). The client's request specifies a set of
> > <snip>
> >
> >
> > > a) to issue 'n' asynchronous requests,
> > > b) waiting for them all to return, or for a timeout limit to be
>reached.
> > >
> > >JMS provides a solution for part (a). However, the EJB spec precludes the
> > >session bean from blocking on the completion of the set of async requests, or
> > >the expiration of the timer.
> >
> > I can't see any reason why a session bean cannot do b). The way I understand it
> > a session bean could easily do the following:
> > 1. Get X nr of JMS queues/topics
> > 2. Send messages to the queues/topics
> > 3. Do receive() on each of the X queues/topics
> > 4. Compute result and return once all receive()'s have completed
> >
> > Why do you say this is not possible?
> >
> > /Rickard
> >
> > ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
