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