From: Georg R. <geo...@gm...> - 2001-06-16 04:46:16
|
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 |_|_\ |___ geo...@gm... +49 (40) 23 53 27 10 |