This one time, at band camp, Jakob Praher said:
JP>I should add that I am using a timestamp on this database entry, and
JP>that with 0.9.4.2 it now says:
JP>
JP>Exception in thread "main"
JP>org.exolab.castor.jdo.ObjectModifiedException: Transaction aborted:
JP>Object of type at.oegam.pge.domain.sekurit.UserInfoDO with identity
JP>1.002 has been modified by a concurrent transaction (cache entry is
JP>different from database row)
JP>
JP>this is probably because of the auto value of the timestamp column, but
JP>I can't imagine as it only get's set, when a change operation is
JP>executed. (so when data is changed, not when it is queried ) ?!!
JP>
JP>thanks
JP>
JP>--Jakob
JP>
JP>
JP>Am Fre, 2003-02-07 um 15.25 schrieb Jakob Praher:
JP>> hi all,
JP>> (especially Bruce, who helped me once or more times in the past ;-))
JP>>
JP>> it's been a while since I post my last message on this forum (probably
JP>> not a bad sign ;-)) - serious : kudos to all.
JP>>
JP>> I am on a jdo project again, and have the following scenario (running
JP>> test cases)
JP>>
JP>> I create a Database in the TestMain, call begin( ) and hand this
JP>> Database instance to a TestCase.
JP>> In the TestCase I use the *same* Database instance and execute a Query
JP>> (with AccessMode Shared), but I don't change the objects at all, just
JP>> check that the ascending mode for timestamp is correct.
JP>>
JP>> everything works fine until the Thread returns to the TestMain again,
JP>> where I call the db.commit( ) to commit changes. Suddenly I get a
JP>>
JP>> ..... as been modified by a concurrent transaction
JP>> at
JP>> org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:867)
JP>> at
JP>> org.exolab.castor.persist.ClassMolder.store(ClassMolder.java:1584)
JP>> at
JP>> org.exolab.castor.persist.LockEngine.store(LockEngine.java:758)
JP>>
JP>> exception.
JP>>
JP>> I could circumvent it by setting the AccessMode to ReadOnly, but somehow
JP>> it worries me that this happens, even if the Database is the same
JP>> instance, and there exist just one call to begin() and commit( ) - so
JP>> where does that "concurrent transaction" come from?
JP>>
JP>> I am using castor-0.9.4.1.jar (allthough currently downloadin 4.2 ;-))
Jakob,
The ObjectModifiedException can be thrown when a field fails Castor's
dirty check (which uses .equals()). This can occur when using fields of
type float, double, date, etc. You say that you're using a Timestamp
field and this could be the offender. Try to isolate that fields by
instructing Castor not to perform its dirty check on it like so:
<sql name="foo" type="date" dirty="ignore" />
See if the ObjectModifiedException goes away after taking this step.
This might then lead you down the road of locating the actual
problem.
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
