Hi,
Just a post concerning the concurrency in DFC for the error :
DfException:: THREAD: http-0.0.0.0-0.0.0.0-9080-5; MSG: [DM_SYSOBJECT_E_CANT_SAVE]error: “Cannot save 0902xxxxxxxx15 sysobject.”; ERRORCODE: 100; NEXT: DfException:: THREAD: http-0.0.0.0-0.0.0.0-9080-5; MSG: [DM_SYSOBJECT_E_VERSION_MISMATCH]error: “save of object failed because of version mismatch: old version was 30”; ERRORCODE: 100; NEXT: null
…
Followed by: DfException:: THREAD: http-0.0.0.0-0.0.0.0-9080-5; MSG: [DM_SYSOBJECT_E_VERSION_MISMATCH]error: “save of object failed because of version mismatch: old version was 30”; ERRORCODE: 100; NEXT: null
Summary:
- Optimistic concurrency control (OCC) assumes that multiple transactions can frequently complete without interfering with each other. While running, transactions use data resources without acquiring locks on those resources. Before committing, each transaction verifies that no other transaction has modified the data it has read. If the check reveals conflicting modifications, the committing transaction rolls back and can be restarted.
- All objects in repository have i_vstamp attribute that incremented automatically after save action. Content server checks whether i_vstamp specified is actual or not, so concurrent modification of sysobjects can throw either DM_SYSOBJECT_E_VERSION_MISMATCH or DM_OBJ_MGR_E_VERSION_MISMATCH errors.
- When any server error occurred, CS marks the current transaction invalid, so, to modify multiple objects consistently it is necessary to perform changes in explicit transaction.
Source : a very good article https://blog.documentum.pro/2014/01/19/concurrency-patterns-in-dfc-optimistic-locking/
That’s all!!!
Huseyin