Not quite sure about this, but I believe the EJB specs prohibits concurrent
threads from accessing the same EJBObject simply because only the original
thread that did the lookup will have Principal info... This topic has been
debated many times before, and is obviously a weak spot in the specs,
confusing both vendors as well as bean developers!
Gene
-----Original Message-----
From: Ang Meng Hua [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 22, 2001 10:38 PM
To: [EMAIL PROTECTED]
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".