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 ?
|
3 answers
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. On Fri, 17 Apr 2009 07:38:05 +0000, vssinha wrote: I wanted to know how getWorkingCopy works. If there is already a service 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 |
Jared Burns (4.5k●2●9)
| answered Apr 21 '09, 10:04 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
On Fri, 17 Apr 2009 07:38:05 +0000, vssinha wrote:
I wanted to know how getWorkingCopy works. If there is already a service 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 |
|
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.