Message Driven Beans
Venkatesh Kumar
Ranch Hand
Posts: 68
Sudhir V
Ranch Hand
Posts: 143
posted 13 years ago
The programing definition of reentrant says "computer program or routine that is written so that the same copy in memory can be shared by multiple users."
http://searchvb.techtarget.com/sDefinition/0,,sid8_gci212881,00.html
HFE Pg 444 cites that Multiple messagebeans of the same type can process messages concurently, however container makes sure that each bean is thread safe i.e. each bean is allowed to execute one message at a time. Hence container makes sure that the bean instances are non-reentrant.
For Stateless beans also only a single client can be connected to a bean instance at a given time.
In case of entity beans multiple clients can access a single entity at the same time however the container ensures that the transactions are atomic.
http://searchvb.techtarget.com/sDefinition/0,,sid8_gci212881,00.html
HFE Pg 444 cites that Multiple messagebeans of the same type can process messages concurently, however container makes sure that each bean is thread safe i.e. each bean is allowed to execute one message at a time. Hence container makes sure that the bean instances are non-reentrant.
For Stateless beans also only a single client can be connected to a bean instance at a given time.
In case of entity beans multiple clients can access a single entity at the same time however the container ensures that the transactions are atomic.
Sudhir V<br />(SCJP 1.2, SCWCD, OCA, SCBCD)
Reid M. Pinchback
Ranch Hand
Posts: 775
posted 13 years ago
For Stateless beans also only a single client can be connected to a bean instance at a given time.
In case of entity beans multiple clients can access a single entity at the same time however the container ensures that the transactions are atomic.
What you say is correct, although I think there is some potential for confusion here between transaction handling and re-entrancy that may not be obvious if you haven't hit the problem before. The problem comes up in a chain of calls like:
entity bean instance 1 invokes bean instance 2,
which in turn tries to invoke another method on entity bean instance 1.
If your DD for entity bean 1 has <reentrant>False</reentrant> then the application will hang. For most apps you'd probably find that <reentrant>True</reentrant> would still give you behaviour that was atomic but without your application hanging.
In case of entity beans multiple clients can access a single entity at the same time however the container ensures that the transactions are atomic.
What you say is correct, although I think there is some potential for confusion here between transaction handling and re-entrancy that may not be obvious if you haven't hit the problem before. The problem comes up in a chain of calls like:
entity bean instance 1 invokes bean instance 2,
which in turn tries to invoke another method on entity bean instance 1.
If your DD for entity bean 1 has <reentrant>False</reentrant> then the application will hang. For most apps you'd probably find that <reentrant>True</reentrant> would still give you behaviour that was atomic but without your application hanging.
Reid - SCJP2 (April 2002)
Kathy Sierra
Cowgirl and Author
Rancher
Rancher
Posts: 1589
5
posted 13 years ago
Just wanted to add that ONLY entity beans have the *option* of allowing reentrant calls. Session beans and MDBs don't have that as an option.
Reid's explanation is the one to pay attention to:
bean 1 calls bean 2... and somewhere bean 2 calls bean 1
So... what do you end up with? If this were a *real* call stack you'd have a call to bean 1 on the stack, then bean 1's call to bean 2, then bean 2's call back to a bean 1 method would be on top. This doesn't sound like it should be a tx problem, because the transaction is associated with the thread... and it *looks* like we have just a single thread stack of execution.
BUT... we're talking about beans. And bean 1 doesn't *really* call bean 2 and bean 2 doesn't *really* call bean 1 again. Everything goes through the Container via the EJB object. And the Container might be managing all of this using multiple threads, even though the Container is protecting your beans and keeping them thread-safe.
So to the Container, it cannot necessarily tell the difference between a reentrant call (bean 2 calling back to bean 1 as part of the *virtual-but-not-REAL call stack*) and simply a new call to bean 1 while bean 1 is already in a method call. In other words, the Container doesn't KNOW that bean 2's call back into bean 1 is part of the same original method call (which means that it isn't a problem), and for all the Container knows... this second call into bean 1 is really coming from some *other* client.
This means that while reentrant calls are not technically a problem, if you tell the Container to ALLOW them, then you are ALSO telling the Container to just allow calls that might, in fact, be compromising your thread safety. You're telling the Container "trust me... I know what I'm doing and if these multiple calls come in to the same bean instance you can just relax. It's just a reentrant call and not a new client..."
That's why in the spec even, you're discouraged from ever allowing reentrant entity beans. But they permit it because you might have a design that absolutely requires it.
Anyway, it applies only to entity beans. Session beans can't allow reentrant calls even if they beg, plead, cry, and threaten.
cheers,
Kathy
Reid's explanation is the one to pay attention to:
bean 1 calls bean 2... and somewhere bean 2 calls bean 1
So... what do you end up with? If this were a *real* call stack you'd have a call to bean 1 on the stack, then bean 1's call to bean 2, then bean 2's call back to a bean 1 method would be on top. This doesn't sound like it should be a tx problem, because the transaction is associated with the thread... and it *looks* like we have just a single thread stack of execution.
BUT... we're talking about beans. And bean 1 doesn't *really* call bean 2 and bean 2 doesn't *really* call bean 1 again. Everything goes through the Container via the EJB object. And the Container might be managing all of this using multiple threads, even though the Container is protecting your beans and keeping them thread-safe.
So to the Container, it cannot necessarily tell the difference between a reentrant call (bean 2 calling back to bean 1 as part of the *virtual-but-not-REAL call stack*) and simply a new call to bean 1 while bean 1 is already in a method call. In other words, the Container doesn't KNOW that bean 2's call back into bean 1 is part of the same original method call (which means that it isn't a problem), and for all the Container knows... this second call into bean 1 is really coming from some *other* client.
This means that while reentrant calls are not technically a problem, if you tell the Container to ALLOW them, then you are ALSO telling the Container to just allow calls that might, in fact, be compromising your thread safety. You're telling the Container "trust me... I know what I'm doing and if these multiple calls come in to the same bean instance you can just relax. It's just a reentrant call and not a new client..."
That's why in the spec even, you're discouraged from ever allowing reentrant entity beans. But they permit it because you might have a design that absolutely requires it.
Anyway, it applies only to entity beans. Session beans can't allow reentrant calls even if they beg, plead, cry, and threaten.
cheers,
Kathy
Keith Rosenfield
Ranch Hand
Posts: 277
posted 13 years ago
Hey Kathy,
Your explanation has helped clear up some of the cobwebs in my mind but I still am a bit cloudy on this subject.
You said:
Can you give a concrete example of how thread safety would be compromised.
This would help me get a better understanding of reentrancy.
Thanks.
Your explanation has helped clear up some of the cobwebs in my mind but I still am a bit cloudy on this subject.
You said:
This means that while reentrant calls are not technically a problem, if you tell the Container to ALLOW them, then you are ALSO telling the Container to just allow calls that might, in fact, be compromising your thread safety.
Can you give a concrete example of how thread safety would be compromised.
This would help me get a better understanding of reentrancy.
Thanks.
Keith Rosenfield<br />SCJP<br />SCWCD<br />SCBCD
| Consider Paul's rocket mass heater. |