I was having a problem today and I searched the archives and found several
posts from people (including myself) with the same problem. Some of them
from a year or more ago.
The problem is as follows. You have two classes Class A and Class B. Class A
has a 1-to-1 relationship to Class B (This may affect 1-to-N relationships
also, I don't know). Create a new instance of Class A and call setClassB(),
passing in an instance of Class B that was obtained from the database in a
different transaction. Then call database.create() and pass the new Class A
object as the argument. You will get a duplicate entry exception from the
database, because JDO tries to insert the instance of Class B with a
different primary key. I hop this explanation is understandable.
I sat down and spent a few hours tracking down the cause of this problem and
found it. If you look at the source code for
org.exolab.castor.persist.ClassMolder in version 0.9.5 on line 1009 there is
the following code:
tx.markCreate( fieldEngine, fieldClassMolder, o, null );
Basically it blindly does an insert of any related objects that are not
registered with the current transaction. The object of the relationship will
never be registered with the transaction, because it was loaded from a
different transaction.
What should happen is that the object should be chaecked to see if it is
TimeStampable and is still in the cache. If it was loaded in a different
transaction and is still in the cache, then tx.markUpdate() should be called
instead of tx.markCreate(). So, I changed the previously mentioned line to
read:
if ((fieldClassMolder._timeStampable == true) &&
(((TimeStampable)o).jdoGetTimeStamp() > 0))
tx.markUpdate( fieldEngine, fieldClassMolder, o, null );
else
tx.markCreate( fieldEngine, fieldClassMolder, o, null );
That change makes my code work. The problem is that I am not familiar with
all the JDO code, so I don't know if calls to database.update() will suffer
the same problem. I also do not know if this will break other parts of the
code. Could someone who knows more about how the JDO code is structured take
a look at this problem and fix to see if there is a more appropriate fix.
Thanks,
Frank
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
