This one time, at band camp, Pletzer, Martin (ext. Mitarbeiter) said:
PMeM>we have a strange problem with CASTOR as persistence manager.
PMeM>
PMeM>We use a access="shared" in our mapping file.
PMeM>In our webApp (tomcat 4.1.2) I'm loading an Object through CASTOR from our
PMeM>DB.
PMeM>I change values, UPDATE the object: everything works fine.
PMeM>I close the browser.
PMeM>I open a new browser, load the same Object from DB (everything is fine so
PMeM>long, I can see my recent changes),
PMeM>but when I try to UPDATE the Object again I get the well known
PMeM>ObjectModifiedException: Timestamp mismatch!
PMeM>The only way I can make things run again is to restart my tomcat.
PMeM>
PMeM>By the way the timestamp is saved as a property onto the Object itself and
PMeM>transported to and from the client via hidden fields.
PMeM>Nothing uncommon I guess.
PMeM>
PMeM>For me it looks like Castor is not closing the (long) transactions!?
...
PMeM>PersistenceException in update: Timestamp mismatched!
Martin,
This is not an issue with Castor not closing the transaction. This is an issue
with the cache containing information that does not match what it believes to
be current. I suggest that you take a look at the cache eviction code in the
Database object, specifically, the expireCache() method:
http://www.castor.org/javadoc/org/exolab/castor/jdo/Database.html#expireCache(java.lang.Class[],%20java.lang.Object[])
This code was added to address exactly these types of concerns. It allows for
manual eviction of objects from the cache.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
