-----Original Message-----
>From: May, Darrell [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, August 16, 2001 6:34 AM
>To: [EMAIL PROTECTED]
>Subject: Re: [castor-dev] Issue with 2 updates on a record in the same
transaction...
>
>The object is the
same instance.
>I first tried
AutoStore to true but it didn't work.
>
>Basically what we
are doing is importing data from a system, data comes in the form of xml files.
>These XML files
contain update/add/change records. Each file is processed within one
transaction.
>There is one main
EJB method that is the main loop and calls 2 or 3 other EJBs to
insert/update/delete as dictated by the xml file.
>Each EJB uses a
castor utility class that contains the JDO object as a static member.
>
>I've tried a very
simple case, 2 ejbs say A and B.
>
>EJB B has one
method: UpdateRecord(Object foo)
>UpdateRecord gets
the an object from castor using a castor utility.find(String query) method.
>It then sets all
the properties of foo to this object obtained from castor. If have verified
that the object returned by the query is the same if called multiple times for
the same key.
>
>EJB A, creates 2
Objects with the same properties, and calls B.UpdateRecord() twice. The
second fails.
What do you mean same properties? Does they
have same identity?
What do you mean twice? Do you mean one for
each new object? Or, you mean twice for each new object?
I still doubt you’re updating with the
same instance base on your description, even you confirmed me.
Anyway, if it is the same instance, then
you can simply add the following code in your program:
if ( !db.isPersistence( objectTobeUpdate ) {
db.update( objectToBeUpdate
);
}
If they are the same instance, the above
should solve your problem.
Castor always takes the snap shot of the
object state at the commit time. When is the object being updated do not
matter.
>We are using oracle
and have our database in JNDI, and connectionPooling is set to true.
>
>Everything works
if I comment out this line:
>
>throw new
DuplicateIdentityException( "update object which is already in the
transaction" ); in TransactionConext.java.
>
>We have imported
over 700 files so far and have had no data problems with this fix.
The throw clause is very necessary and
is there for a purpose.
Thomas
>-----Original
Message-----
>From: Thomas Yip
[mailto:[EMAIL PROTECTED]]
>Sent: Thursday,
August 16, 2001 1:41 AM
>To:
[EMAIL PROTECTED]
>Subject: Re:
[castor-dev] Issue with 2 updates on a record in the same transaction...
>Is the object to
be updated the same instance?
>
>If not, it
shouldn’t be done. One instance per identity of the same type rule can be
broken. Otherwise, it is causing some undeterminable behavior. Because Castor
is not designed to deal with that.
>
>Otherwise, try to
setAutoStore( true ). That mode is more forgiving on multiple update.
>
>
>Thomas
>
>
>
>-----Original
Message-----
>>From: May,
Darrell [mailto:[EMAIL PROTECTED]]
>>Sent:
Wednesday, August 15, 2001 7:54 AM
>>To:
[EMAIL PROTECTED]
>>Subject:
[castor-dev] Issue with 2 updates on a record in the same transaction...
>>
>>We are using
Castor with Jrun and have run into an issue with updating the same record more
than once inside the same transaction.
>>The exception
is DuplicateIdentityException: update object which is already in the
transaction.
>>I have found
that it's thrown on line 904 in TransactionContext.java, here's a snip of code:
>>
if ( entry != null ) {
>>
if ( entry.deleted )
>>
throw new ObjectDeletedException(
Messages.format("persist.objectDeleted", object.getClass(), identity
) );
>>
else
>>
throw new DuplicateIdentityException( "update object which is already in
the transaction" );
>>
}
>>We have the
need to allow updates to the same record more than once, with the behavior that
the last update is the one that is commited.
>>We have
modified the code temporarily to:
>>
if ( entry != null ) {
>>
if ( entry.deleted )
>>
throw new ObjectDeletedException(
Messages.format("persist.objectDeleted", object.getClass(), identity
) );
>>
//else
>>
//throw new DuplicateIdentityException( "update object which is already in
the transaction" );
>>
}
>>And this
seems to work perfectly for us. Does anyone see any side affects from
this?
>>It would be
nice to engineer this as to set this behavior on and off.
>>Darrell May
>>Software
Architect
>>Cyberplex
>>Waterloo
Development Center
>>[EMAIL PROTECTED]
>>http://www.cyberplex.com
>>
>
