Ok, I
have a small update on the particular problem I was researching I've identified
one problem with our code. We were attempting to persist and object with a
compound key ( one of the values being it's rank in a list ). We received
the error because we were trying to change this rank value and then update the
object. Since rank is part of the identity, changing this value would
produce and error, presumably because it would produce a different OID object
whose timestamp would be 0, as compared to the original (i.e. unmodified
object). The simple work around, delete the old record and re-insert the
updated one.
Vincent Techeira
-----Original Message-----
From: Techeira, Vincent X. -ND
Sent: Wednesday, June 11, 2003 5:21 AM
To: '[EMAIL PROTECTED]'
Subject: More on TimeStamp Mismatch Error: Bug 1107After doing an extensive step through of the code (debuggers are a beautiful thing no matter what anyone says) I think I've identified at least on instance where the error occurs.To give some context to the discussion consider the follow XML snippet at the end of this message.Now having stepped through quite a bit of the code I noted while the object ( on which update was called ) had a timestamp, the relevant Castor info to check this did not have a timestamp. More specifically, the update method of org.exolab.castor.persist.ClassMolder executes it does not detect a timestamp. As of line 1758 of this class (where I first see the exception in my execution path) the:oid (org.exolab.castor.persist.OID) variable still had it's _stamp variable set to null,locker (org.exolab.castor.persist.ObjectLock) variable still had it's _timeStamp variable set to 0,lockTimestamp (int) variable was still set to 0If these conditions exist that it would seem quite apparent we would have a mismatch. I suspect ( perhaps incorrectly ) that this may be tied to some other unique behaviour I noted when stepping through this code. Since I'm calling an update I expected the locker to attempt acquire a write lock. Instead it never does when the acquireUdateLock method is called on the locker object. The_gateCount variable does get incremented and decremented_confirmWaiting variable gets set to the transaction (i.e. the org.exolab.castor.jdo.engine.TransactionContextImpl reference available)_confirmWaitingAction variable gets set to 4.Also of note is that _accessMode (org.exolab.castor.mapping.AccessMode) name attribute is set to "read-only". This is expected since that's what defined int he mapping file. However suggestedAccessMode (org.exolab.castor.mapping.AccessMode) is always set to null. The two issues may be related.I hope the information I've provided is not redundant, and is useful towards finally identifying and eliminating this problem If I've made incorrect assumptions based on my understanding of the code, please correct me since I am still digesting the many nuances of the product.Vincent TecheiraXML snippet follows-----------------------------<class auto-complete="false" name="com.wdw.dd.cc.database.valueobjects.global.ProfileObjectRank" access="read-only" identity="g_parent.g_iID g_profile.g_iID g_iRank">
<description>Default mapping for class com.wdw.dd.cc.database.valueobjects.global.ProfileObjectRank</description> <cache-type type="unlimited"/> <map-to table="PRFL_OBJ_RANK" xml="profile-object-rank"/><field required="true" transient="false" direct="false" name="g_parent.g_iID" type="integer" lazy="false">
<sql name="rank_id" dirty="check" type="integer" read-only="false"/>
</field>
<field required="true" transient="false" direct="false" name="g_profile.g_iID" type="integer" lazy="false">
<sql name="prfl_val_id" dirty="check" type="integer" read-only="false"/>
</field> <field required="true" transient="false" direct="false" name="g_iRank" type="integer" lazy="false"> <sql name="prfl_obj_rank_nb" dirty="check" type="integer" read-only="false"/></field>
...
</class>
