Question on how getWorkingCopy and saveItem work
I wanted to know how getWorkingCopy works. If there is already a service instance which has the workingCopy of a database item, what would happen to another service instance which also asks for the workingCopy ?
Many time on my server log, I get StaleDataException and save fails. How can I avoid this ?
Many time on my server log, I get StaleDataException and save fails. How can I avoid this ?
om.ibm.team.repository.common.StaleDataException: CRJAZ0322I Expected 1 row, not 0; handle=com.ibm.research.sedna2.sap.common.model.impl.VariantImpl@daa0daa (stateId: , itemId: , origin: <unset>, immutable: true) (modified: 2009-04-17 12:55:36.046, workingCopy: <unset>) (predecessor: ) (id: _raDxQCsfEd6jGKguIJ6wmQ, name: Test Process)
at com.ibm.team.repository.service.internal.dataaccess.AbstractRow.oneOrStaleData(AbstractRow.java:321)
at com.ibm.team.repository.service.internal.dataaccess.UpdateItemCurrentRow.validateResult(UpdateItemCurrentRow.java:75)
at com.ibm.team.repository.service.internal.dataaccess.BatchingRowReceiver.simulatedBatch(BatchingRowReceiver.java:371)
at com.ibm.team.repository.service.internal.dataaccess.BatchingRowReceiver.executeBatch(BatchingRowReceiver.java:264)
at com.ibm.team.repository.service.internal.dataaccess.BatchingRowReceiver.execute(BatchingRowReceiver.java:200)
at com.ibm.team.repository.service.internal.dataaccess.IRowReceiver$IRowReceiverLocator.executePendingChanges(IRowReceiver.java:140)
at com.ibm.team.repository.service.internal.dataaccess.FlushingMediatorService.flush(FlushingMediatorService.java:56)
at com.ibm.team.repository.service.internal.dataaccess.FlushingMediatorService.update(FlushingMediatorService.java:81)
at com.ibm.team.repository.service.internal.RdbRepositoryDataMediator.updateSimpleItem(RdbRepositoryDataMediator.java:1606)
at com.ibm.team.repository.service.internal.RepositoryItemService.doUpdateSimpleItem(RepositoryItemService.java:1560)
3 answers
On Fri, 17 Apr 2009 07:38:05 +0000, vssinha wrote:
If an item is modified *after* you fetch it, you'll get a
StaleDataException if you try to modify the item yourself and save it. I
don't think there's any way to really avoid this.
But in the Process component, our service does try to hide the problem
when we can. If a StaleDataException occurs when we're trying to save an
item, we have a bit of code we wrote that tries to automatically merge
the incoming changes with the latest state of the item. If it's a simple
merge (if non-overlapping fields have been modified), this results in the
item being saved cleanly despite the StaleDataException that occurred. If
there are conflicting changes, we just re-throw the StaleDataException.
--
Jared Burns
Jazz Process Team
I wanted to know how getWorkingCopy works. If there is already a service
instance which has the workingCopy of a database item, what would happen
to another service instance which also asks for the workingCopy ?
Many time on my server log, I get StaleDataException and save fails. How
can I avoid this ?
If an item is modified *after* you fetch it, you'll get a
StaleDataException if you try to modify the item yourself and save it. I
don't think there's any way to really avoid this.
But in the Process component, our service does try to hide the problem
when we can. If a StaleDataException occurs when we're trying to save an
item, we have a bit of code we wrote that tries to automatically merge
the incoming changes with the latest state of the item. If it's a simple
merge (if non-overlapping fields have been modified), this results in the
item being saved cleanly despite the StaleDataException that occurred. If
there are conflicting changes, we just re-throw the StaleDataException.
--
Jared Burns
Jazz Process Team
Hi ,
I found this topic really helpful as i am trying to create a follow up condition for workitem save operation.In my condition i want to create approval records on workitem save operation.This is giving me staleDataException and reason is quite obvious.
As you have said in this forum the workaround is to merge the latest state of workitem with the incoming changes, can you elaborate on this or give me some code snippet how to do this.
Thanks in advance.
If an item is modified *after* you fetch it, you'll get a
StaleDataException if you try to modify the item yourself and save it. I
don't think there's any way to really avoid this.
But in the Process component, our service does try to hide the problem
when we can. If a StaleDataException occurs when we're trying to save an
item, we have a bit of code we wrote that tries to automatically merge
the incoming changes with the latest state of the item. If it's a simple
merge (if non-overlapping fields have been modified), this results in the
item being saved cleanly despite the StaleDataException that occurred. If
there are conflicting changes, we just re-throw the StaleDataException.
--
Jared Burns
Jazz Process Team
I found this topic really helpful as i am trying to create a follow up condition for workitem save operation.In my condition i want to create approval records on workitem save operation.This is giving me staleDataException and reason is quite obvious.
As you have said in this forum the workaround is to merge the latest state of workitem with the incoming changes, can you elaborate on this or give me some code snippet how to do this.
Thanks in advance.
On Fri, 17 Apr 2009 07:38:05 +0000, vssinha wrote:
I wanted to know how getWorkingCopy works. If there is already a service
instance which has the workingCopy of a database item, what would happen
to another service instance which also asks for the workingCopy ?
Many time on my server log, I get StaleDataException and save fails. How
can I avoid this ?
If an item is modified *after* you fetch it, you'll get a
StaleDataException if you try to modify the item yourself and save it. I
don't think there's any way to really avoid this.
But in the Process component, our service does try to hide the problem
when we can. If a StaleDataException occurs when we're trying to save an
item, we have a bit of code we wrote that tries to automatically merge
the incoming changes with the latest state of the item. If it's a simple
merge (if non-overlapping fields have been modified), this results in the
item being saved cleanly despite the StaleDataException that occurred. If
there are conflicting changes, we just re-throw the StaleDataException.
--
Jared Burns
Jazz Process Team