-----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
>>
>
