Hi, I encountered the same exception during a long transaction in a castor0.9.4 + jboss-3.0.3_tomcat-4.1.12 + castor-jdo-plugin for Version 3.0 Environment. I'm using a stateless session bean ( I modified the rooms2-example provided on the jboss-page ) and I'm getting the same exception with my dao's as Ruslan reported below. Changing the id from 'int' to 'java.lang.Integer' in the mapping and in the bean fixed the error and all works well. Currently I have little time for testing this, but pherhaps it would be interesting if the rooms2 Example shows the same behaviour if the identities are set to 'int' (currently Strings are used for identity). Bruce, could this test be helpful?
Regards, Thomas Bruce Snyder wrote:
This one time, at band camp, Ruslan Gainutdinov said:----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
RG>I have a long transaction where in one thread, at some point of time I load
RG>object from database. Then at server`s shutdown (or at object cache flush -
RG>my own cache, not castor`s) I db.update() those objects, sequentially.
RG>
RG>I get following exception:
RG>org.exolab.castor.jdo.ObjectModifiedException: Invalid object timestamp
RG>detected.
RG> at
RG>org.exolab.castor.persist.ClassMolder.update(ClassMolder.java:2028)
RG> at org.exolab.castor.persist.LockEngine.update(LockEngine.java:638)
RG>
RG>If I do the same thing, load in one db.begin()/db.end(), and update in
RG>other, during one servlet doGet() session - everything goes fine.
RG>
RG>If I change so getId(), setId() methods accept not primitive type int, but
RG>object java.lang.Integer - everything starts working fine.
RG>
RG>Where should I dig on this matter? Is primitive identity fields fully
RG>supported? Because, I understand, there is a way to distinuguish with
RG>java.lang.Integer, do we have identity field or not - field will be null if
RG>we don`t. But with primitive type there is always some value, -1, 0, 1....
RG>and no way to say which of them is no-identity.
Ruslan,
Primitive identities are supported just fine in Castor. I've never
heard of this type of problem with Castor. Please explain further your
question about the use of a java.lang.Integer and no way to distinguish
do we have an identity or not. I'm not sure, but you may have hit upon
something here.
I'm also curious to know how you're using your own cache with Castor. Are
you simply disabling Castor's cache in the mapping descriptor and manually
calling your own cache implementation? If not, please explain more and
post your mapping and the relevant client code.
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
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
