when the ejbStore() is called
Hi,
I've the following situation,
I have a stateless session bean, S1
and, Two entity beans E1 and E2.
E1 has a reference (a foreign key column) to the primary key of E2.
Now, in the remote method of S1, I do the following steps,
1. set the E2 reference in E1 as null (this would be persisted to the database in the ejbStore() method of E1)
2. Remove the E2.
Both the entity beans has <trans-attribute>Required</trans-attribute>
NOw my question is,
When will the ejbStore() of E1 will be called, right after the first step in the remote method of S1 or at the end of the transaction (ie., the when the remote method of S1 returns?)
If the ejbStore() methods of both the entities are called before the method in S1 finishes, then what will be the order of ejbStore() methods in E1 and E2.
I've not tried the above scenario.
Any kind of input would be of great help.
Thanx,
vijay
[1017 byte] By [
DVijay] at [2007-9-26 2:10:59]
The store will happen when the transaction is committed.
Could you please tell me in the above scenario, when will the transaction gets commited? (assuming that all goes well without any exception)And more importantly, could you also tell me in which order the ejbStore() will be called ( E1 first or E2 first..)thanx.
You can print a logging message when ejbLoad called.
Is it really important? I presumed you are using entity beans as container managed persistent. In this case when it is called or how is not session beans concern.
ibnul at 2007-6-29 9:02:31 >
vijay,
Presuming the method in your stateless session bean has either CMT with REQ, REQNEW, MAND or you start and stop a transaction within that methods the following occurs:
1) A transaction is started in the stateless session bean method
2) You invoke setRefToNull on E1 (registering resources E1 with the TX manager)
3) You invoke remove on E2 (registering resources E1 with the TX manager)
4) you return to the stateless session bean
the container (In case of CMT sessionbean, otherwise you inform the container to commit the transaction in BMT). The transaction manager now commits the transaction on E1 and then on E2.
Because now the transactions are over the store method of E1 is invoked (obvisously not of E2, which has been removed).
So the ejbStore of E1 is invoked after method call on S1 returns.
Raphael Parree
Thanks guys!.
Raphael,
I appreciate the explanation you have given.
sorry, i didn't mention about the following:
The stateless session bean is a CMT with REQ.
With the above setting, I presume that only one transaction takes place (I'm right I suppose coz all the beans are on transaction attribute Required)
Now the real problem is,
Since E1 is having an attribute that refers to E2,
The following steps occurs in the stateless session bean,
1. A transaction is started in Stateless Session bean method.
2. invoke setRefToNull on E1. (here, the ejbStore is not called yet. so, in the database table for E1, it still holds a reference to E2 i.e, the foreign key is not set to null yet)
3. invoke remove on E2. (which tries to delete itselt) *This step fails because, there are dependent records (child records) are still existing in the database as E1's ejbStore is not called yet.*
HOw to tackle this child record problem?
(I cannot move the code for deleting the child records to E2)
thanx,
vijay
vijay
When the transaction is about to be over, the sequence is as follows:
-E1::ejbStore
-E2::ejbRemove
-Transaction manager starts the Commit sequences
So when the remove is invoked on E2, the reference from E1 should be gone.
Do you actually get a foreign key violation on you code?
Raphael Parree
Hi, I figured it out.. It was a stupid mistake that was causing the problem. Anyway your input was useful to me.thanx.
Well...
I have absolutely the same problem.
In my situation all remove methods invoking just in place the are in program text insight the transaction but all store method are suspended until transaction commit.
So I can not execute this transaction at all.
Now I'm trying to move 'update to null' part of code to separate method with TX_REQUIRE_NEW attribute but I realy want to know is there any other more comfortable way to do it.
Please let me know what is workaround!I have the same problem.oleg.gashnikov@informix.ru
> Hi,> I figured it out..> It was a stupid mistake that was causing the> e problem.> > Anyway your input was useful to me.> > thanx.If you solved a problem it would be nice to share it with others
cendo at 2007-6-29 9:02:31 >
