Hi all,
trying to sort that out.
David Esposito showed us a perfectly OK sequence of modifications
to some Entity beans within one TX. He reported problems with JBoss
accessing the DB while persisting, because of changed order of
modifications, creates/deletes seem to be done before updates,
regardless of the OO sequence of calls.
This comes surprising to me, anybody around to tell, if and why
this is the case? Is it only with CMP somehow, I can't see this
with BMP?
Everything would be OK, if JBoss did sync in the very same order
to the DB as the OO code requested it. Regardless of doing the
ejbStore() at the end of TX or after calling a business method:
just do it in the same order. Even intermixed stores would be
no problem, when done IN THE SAME ORDER (this respecting the
recent change to finders doing a store before finding, as requested
by EJB spec 2.0).
Please remember: a TX on a DB actually SEES the changes it has
done in it, although no other TX can see that until commit.
Now to the RI (referential integrity) thing:
A DB RI setting of ON DELETE CASCADE must be considered as beeing
another application modifying the DB concurrently to JBoss, so
the commit option HAS to be set to at least B, and the code in
the beans then MUST be prepared to accept concurrent changes
by some app outside JBoss and handle that gracefully. I.e. in
Davids case he must be prepared to expect cc.setRecord() to fail
IF HE HAD called mca.remove() HIMSELF BEFORE or IF HE HADN'T
FETCHED mca BEFORE modification to cc ... but his code still is OK.
A DB RI setting of checking validity of Foreign Keys should not
be problematic even with commit option A (note off topic: depending
on your mapping of inheritance to your DB this COULD be a problem).
Besides, not changing the order of access to the DB leaves control
of LOCKING to the bean implementor, thus DEADLOCK avoidance is to
him ... but he hasn't the same possibilities, as the typical
relational DB developer has: the RDB developer always can ROLLBACK
when he discovers, that some required lock can't be aquired (SELECT
... FOR UPDATE NOWAIT for Oracle, similar for other RDMS's).
The EJB developer is lost here, the spec simply drops him
'serialized' possibly waiting for a bean held by his competitor
which itself is blocked cyclic. The only way to handle deadlock
is 'ordered access', which in practice seems to be impossible,
especially respecting the above requested access to the DB in
the same order, as the OO code needs/expects it.
There is a hint in the EJB specs 1.1, that the container might
reorder access to the DB to actually try ORDERED access to the
DB (i.e. in increasing PK order) to avoid deadlock. But I just
now can't come up with a pattern, that is safe and avoids deadlock,
any taker?
Conclusion: today let JBoss respect the OO order of access to
beans and do it the same way to the DB.
regards
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
