So if I prefer to build a thread in my client app that goes out and
'asynchronously' invokes an eJB, I would be doing work in the client which
shd be handled by the eJB. Is that the 'con'? It would seem to be a minor
one, given Java's support for multithreading. Or am I oversimplifying?
Thanks
Rickard
�berg <[EMAIL PROTECTED]> on 10/20/99 09:53:13 AM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: pankaj tandon/MIS/genco/US)
Subject: Re: EJB cons?
Hey
Pankaj Tandon wrote:
> Can you please elaborate on what you mean by eJB being a synchronous
model.
> (An example would really help).
Synchronous:
A client object makes a call to a server object and waits for it to
return the result. I.e. a "normal" method call.
Asynchronous:
A client object makes a call to a server object which returns
immediately so that the client can continue its work. At the same time
the server processes the request in parallel. A.k.a. asynchronous
messaging, as used in JMS.
As Ian noted, it would be very useful if beans having special
characteristics (specifically no return value and no application
exceptions) could be called asynchronously. It would make EJB
applications tremendously more scalable and useful.
/Rickard
--
Rickard
�berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
