Hi Ang,
A lot has been discussed on this thread. I will advise you to check out the
archives of the list. Definitely read Jonathan Weedon mail for detail on how
their application server handle such scenario.
The question as to how different server vendor handle the scenario, as you
described, depends on the concurrency support and the implementaion can be
very specific. To support a pessimistic strategy, one bean instance may be
used, and to support optimistic strategy more than one bean instances may be
used. Anyway, with optimistic strategy, client has to handle the transaction
collision.
Regards,
Hemant
www.pramati.com
----- Original Message -----
From: "Ang Meng Hua" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 11:08 AM
Subject: Concurrency issues on entity bean
Does anyone has the answer to the following scenario?
Client has a remote reference to an entity bean.
Spawned off two threads that uses the remote reference to invoke
methods on the entity bean.
If optimistic concurrency is used by the container, i.e multiple instances
are used to serve different transactions, are the two threads dealing
with different bean instances or just one?
If both threads are interacting with the same bean instance, that would
mean that client remote reference is "pinned" to an instance of the entity
bean, unlike stateless session bean, is that right?
How does the container handle the above scenario?
===========================================================================
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".
