Hello,
we have come to the conclusion that there is a bug in the rollback mechanism of Castor JDO. The problem occurs whenever you are doing a rollback on a transaction which has touched two persistent objects of different types (say types A and B), which are both referring to an object of a third type (say type C):
A -> C <- B
The problem only occurs if the access-mode is db-locked.
What happens, when you now call rollback?
1. Object A is reverted and released
2. This means all of it's objects are reverted and released, so this happens also to object C
3. Now object B is reverted, which means, all of it's objects are reverted
4. This ends up in "case FieldMolder.PERSISTANCECAPABLE:" in the method ClassMolder.revertObject()
5. TransactionContext.fetch() is called for object C
6. This method checks, if the accessMode is DbLocked (which is true for us) and if the current object (our object C) is locked.
7. The object is not locked (it has been released in step 2), so the
This is exactly what happens to us if we call rollback:
org.exolab.castor.jdo.PersistenceException: Lock conflict: attempt to load object of type C with identity XXX in two different locks modes (exclusive and non exclusive) in the same transaction
at org.exolab.castor.persist.TransactionContext.fetch(TransactionContext.java:512)
at org.exolab.castor.persist.ClassMolder.revertObject(ClassMolder.java:2532)
at org.exolab.castor.persist.LockEngine.revertObject(LockEngine.java:855)
at org.exolab.castor.persist.TransactionContext.rollback(TransactionContext.java:1726)
at org.exolab.castor.jdo.engine.DatabaseImpl.rollback(DatabaseImpl.java:519)
Unfortunately the table row remains locked until the JVM (in our case the application server) is stopped. In our application this happens quite frequently.
==Workaround==
All of this will not happen if you do not revert the object after it has already been reverted (or not modified at all). This workaround seems to be already included in the Castor source, but it is in comment signs:
In Revision 1.14 of org.exolab.castor.persist.TransactionContext just activate the line 1793: //if ( entry.updateCacheNeeded || entry.updatePersistNeeded )
We would like to recommend this as a fix for one of the next Castor releases. See our questions below.
==Playback==
We have created a small scenario to reproduce the problem basing on the src/examples/jdo/test:
- We added the type NewProduct, which is a smaller version of Product, but like Product references the type ProductGroup
- All tables in mapping.xml are db-locked.
- Rollback does not work at all on the test class Product as it came, because it has no methods setDetails( Vector details ) and setCategories( Vector cats ) so we added them. (This might be considered a bug in the test type).
- We appended a small section to the Test.java class which creates a NewProduct entry and connects it to the ProductGroup. In a following transaction a Product and a NewProduct are db.loaded and then db.rollback() is called.
- If we execute this driver, the application crashes with the exception described above.
If you like I can provide these files.
== Questions==
* Does anybody know, why the line "//if ( entry.updateCacheNeeded || entry.updatePersistNeeded" in the method rollback() of org.exolab.castor.persist.TransactionContext has been commented? It is out since Revision 1.1 on your viewcvs.
* Does anybody have an idea, if there are any side-effects in our "work-around", of activating this line. So far we have noticed none.
If you confirm this bug and accept the workaround, please put it into one of the next releases.
Sincerely,
Christoph Ernst
--
Christoph Ernst (sd&m AG)
dit - Deutscher Investment Trust, Applied Technology
Phone: +49-69-263-16125
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
