You have to be carefull all when making calls to the same stateful session bean
from different client threads.
You can easily wind up getting a reentrant exception. I had a problem where a
client gui would make two seperate
calls to the stateful session bean from two different threads and I ran into
reentrant problems. The 1.0 spec
is somewhat vague in this area. It talks about the container serializing the
method requests but doesn't require it.
Weblogic certainly doesn't doit. I was forced to write a request queue manager
on the client side to ensure I was
only issuing a single request at a time.
derek
Sean C Sullivan wrote:
> I have a stateful session bean called FooSessionBean
>
> In FooSessionBean's deployment descriptor, I specify a DEFAULT
> access control entry value of [mywebfrontclient]
>
> Now let's say that I have 2 threads: t1 and t2
>
> On thread t1, I create FooSessionBean using FooSessionHome.create
>
> On thread t2, I call FooSessionBean.remove (aka EJBObject.remove)
>
> Should this work?
>
> Are there any restrictions that would prevent thread t2
> from invoking EJBObject.remove?
>
> -Sean
>
> ===========================================================================
> 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".
