• 1 reply
  • Latest Post - ‏2012-12-20T10:00:22Z by David_Radley
344 Posts

Pinned topic Exception_Shared_LastUpdateDtNotMatched : Another transaction has updated..

‏2012-12-19T17:34:51Z | mdm-migration

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

=================================Error Message======================
<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 | 182135483056197161</Throwable>
  • David_Radley
    8 Posts

    Re: Exception_Shared_LastUpdateDtNotMatched : Another transaction has updated..

    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.

    regards David.