Couple o Session EJB questions.
Graham VMead
Ranch Hand
Posts: 154
posted 13 years ago
Hi,
First the quickies,
Q1
Does the ejbRemove() method of a Stateful Session EJB have access to its instance variables, I'm getting null when I print them in this method?
Have they been nulled already?
Q2
If I have two Stateful Session EJBs A and B.
If
0) Servlet invokes method on A
1) A gets B's Remote EJBObject
2) Stores its Handle in an instance variable
3) Calls a method on B which completes
4) Control passes back to Servlet
At what point can the container call ejbRemove() on B?? If it does won't this make the handle stored in B invalid???
Q3
Are there restrictions on EJB's calling back to each other/nested calls.
I know this is V V contrived but when I do the following
Two Stateful Session EJBs A and B, Transaction management set to Container but no DB access.
If
0) Servlet invokes method on A
1) A gets B's Remote EJBObject passing in instance of its Remote(EJBObject)
interface to B via the create method
2) Stores B's remote Handle in an instance variable
3) Calls a method on B which calls back on A via the EJBObject in 1)
4) A calls back on B by reacquiring B's Remote EJBObject via the stored Handle stored in 2)
Phew!
Everything goes like a dream until control bubbles back to the initial method call in 3) then wham I get
InvalidBeanOStateException(current = METHOD_READY, expected = IN_METHOD | TX_IN_METHOD | DESTROYED)
Is it something to do with transactions?
If anyone can be bothered to answer
TIA Graham
First the quickies,
Q1
Does the ejbRemove() method of a Stateful Session EJB have access to its instance variables, I'm getting null when I print them in this method?
Have they been nulled already?
Q2
If I have two Stateful Session EJBs A and B.
If
0) Servlet invokes method on A
1) A gets B's Remote EJBObject
2) Stores its Handle in an instance variable
3) Calls a method on B which completes
4) Control passes back to Servlet
At what point can the container call ejbRemove() on B?? If it does won't this make the handle stored in B invalid???
Q3
Are there restrictions on EJB's calling back to each other/nested calls.
I know this is V V contrived but when I do the following
Two Stateful Session EJBs A and B, Transaction management set to Container but no DB access.
If
0) Servlet invokes method on A
1) A gets B's Remote EJBObject passing in instance of its Remote(EJBObject)
interface to B via the create method
2) Stores B's remote Handle in an instance variable
3) Calls a method on B which calls back on A via the EJBObject in 1)
4) A calls back on B by reacquiring B's Remote EJBObject via the stored Handle stored in 2)
Phew!
Everything goes like a dream until control bubbles back to the initial method call in 3) then wham I get
InvalidBeanOStateException(current = METHOD_READY, expected = IN_METHOD | TX_IN_METHOD | DESTROYED)
Is it something to do with transactions?
If anyone can be bothered to answer
TIA Graham
Roger Chung-Wee
Ranch Hand
Posts: 1683
posted 13 years ago
ejbRemove() is called because:
1. The client called remove() on the home or component interface
2. The Container decides to remove the bean after the lifetime of the EJB object has expired.
Note that ejbRemove() is not always called when the bean is destroyed. This would be the case if the bean throws a system exception or if a passivated bean times out. And following a container crash, obviously ...
When the bean is destroyed, its associated EJB object is also destroyed. Any attempt to access a non-existent EJB object causes java.rmi.NoSuchObjectException to be thrown to a remote client or javax.ejb.NoSuchObjectLocalException to be thrown to a local client.
At what point can the container call ejbRemove() on B??
ejbRemove() is called because:
1. The client called remove() on the home or component interface
2. The Container decides to remove the bean after the lifetime of the EJB object has expired.
Note that ejbRemove() is not always called when the bean is destroyed. This would be the case if the bean throws a system exception or if a passivated bean times out. And following a container crash, obviously ...
If it does won't this make the handle stored in B invalid???
When the bean is destroyed, its associated EJB object is also destroyed. Any attempt to access a non-existent EJB object causes java.rmi.NoSuchObjectException to be thrown to a remote client or javax.ejb.NoSuchObjectLocalException to be thrown to a local client.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
