|Potentially, yes.
|The goal of EJB is that you don't have to deal with complex stuff: write
|your bean without worrying of multiple threads, transactions, pooling, etc,
|because the container will take care of all this complexity for you.
|Now if you want to make your bean reentrant, you are telling the container
|"allow loopbacks"; but the container cannot distinguish between a loopback
|and a concurrent call in the same tx context, they looks the same to the
|container. So, by making a bean reentrant you allow also multiple
|threads to
|enter the bean, and hence *you* have to deal with multiple thread problems
|(synchronized methods and the likes). Notice however that must be
|concurrent
|calls *from the same tx context*.
that makes me think simon, are you on top of the "sync on passivation"
issue? Iwanted to look at it.
marc
|
|> How will jBoss handle both situations (if the code is fixed :-) ) ?
|
|jBoss already handle both situations, taking care of multiple threads
|entering an EJB, serializing them if necessary, making them wait for the
|completion of one invocation if it's the case and allowing multiple threads
|in (from the same tx context) if the bean is reentrant. What it does not do
|yet is throwing a RemoteException in case of reentrancy not allowed, but as
|you have experienced, it does not allow you to continue :)
|
|However, think twice before using reentrant beans, most likely you
|can avoid
|them and have a simpler design for your application.
|
|Simon
|
|
|--
|--------------------------------------------------------------
|To subscribe: [EMAIL PROTECTED]
|To unsubscribe: [EMAIL PROTECTED]
|Problems?: [EMAIL PROTECTED]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
