We are trying to understand how to handle concurrent transactions updating the same person record. We are running into the issue below when 2 more threads are trying to update the same person record...what can be done to alleviate this? Is there a database setting, WAS setting? Any advise is appreciated..
<ErrorMessage>Exception_Shared_LastUpdateDtNotMatched: Another transaction has updated the database record you are trying to update. Cannot update record at this time, please try again.</ErrorMessage>
<Throwable>java.lang.RuntimeException: com.dwl.base.exception.LastUpdateDateException: class com.ibm.bh.extension.entityObject.EObjTCRMPersonExt | 182135483056197161</Throwable>
This topic has been locked.
Pinned topic Exception_Shared_LastUpdateDtNotMatched : Another transaction has updated..
2012-12-19T17:34:51Z | mdm-migration
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
David_Radley 120000KY9A8 Posts
Re: Exception_Shared_LastUpdateDtNotMatched : Another transaction has updated..2012-12-20T10:00:22ZThis is the accepted answer. This is the accepted answer.Hello,
As you are probably aware this issue is caused with sequences like:
requester 1) gets person A
requester 2) gets person A
requester 1) updates person A
requester 2) updates person A but the before image of Person A is not up to date. If MDM Server honours this request then it would lose requester 2s update.
So you ask whether there is a DB setting to get round this. There are the isolation levels which effect this. but this is really concerned with concurrent updates, i.e. 2 requests updating the same row. This is not the case here.
CICS has the concept of "get for update" which locks the rows that are read untl the update occurs. MDM Server does not have this concept - "get"s do not cause locks. In an SOA environment, you may not want to leave rows locked in the database until the update occurs - when you do not know when or if the update will come.
If the get and the update are separate soa requests then there could be long time windows when this issue could occur. If this is your case it would be worth considering using a courser grain transaction business proxy; issuing the get and update in quick succession in the same transaction to reduce the window where this might occur.