Hi Christoph,

can you please create a bug report at http://bugzilla.exolab.org, provide
the same descriptive message as part of the bug report and attach the
samples mentioned below. In addition, can you please provide us with

- information what RDBMS you are using.
- instructions how to create the tables required.
- etc.

Thanks
Werner

> 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:5
> 12)
>       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.jav
> a: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]
> 
> 
> 

-- 
+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben



----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to