Auto-Numbering Issue while uploading documents via DFS WS

Dear members,

Functionality: We have designed a custom DFS WS which uploads multiple documents from a portal into Documentum (doc type is sw_m2m_doc). Multiple parallel requests can be invoked for the same. The documents uploaded are being autofiled and autonumbered as per a specific naming combination. The naming convention is like <attr1>-<attr2>-<attr3>-<seqno> (eg., WSZ-CSC-DT-0000056). The latest sequence for a particular attribute combination is stored in sw_sequence object.

Issue: For 5-10 parallel request it's fine. However if more parallel requests like 50-60 are invoked, around 15-20% requests are failing. The error we are having in the logs,

Caused by: com.emc.documentum.fs.services.core.CoreServiceException: Failed to execute DFC operation: Could not check in document 100639330106_20130908_MS.xls

com.documentum.fc.common.DfException: save of object 09044a1480223609 of type sw_sequence failed because of version mismatch: old version was 2,756

Please let us know your views on how we can resolve this issue.

Arindam

Find more posts tagged with

Documentum

Captiva

Comments

arindam.ghosh

NB: We are using synchronize in the WS method.Please let me know if you need more info.

CláudioGil

Hi,

The version mismatch error is an optimistic locking feature in the Documentum object model. Objects have a v_stamp property and any update checks if the v_stamp in the database is the same as the v_stamp in memory.

In general, you can solve your problem with the two typical solutions isolation or retries.

Isolation

The service would start a transaction, lock the object (pessimistic locking), update the object, unlock the object, commit the transaction. As a result you would have a new sequence number and an updated sw_sequence object. You might get lock timeout problems if you have to much concurrency.

Retries

Exactly as you are doing now but you handle the version mismatch error and repeat the operation of getting the sw_sequence object, calculating the next number, and updating it. Normally you attempt this a few (3-10) times before throwing an error (you can imagine this as a timeout in the pessimistic locking scenario).

Also, I don't thing there is a"good" way of identifying a version mismatch exception (like a subtype of DfException) but you can look for the DM_OBJ_MGR_W_VERSION_MISMATCH message id.

Note: The "synchronized" in the WS method only works if you ensure you only use one instance of the WS class and one server. As you might be guessing this is not the case. Otherwise the only way you would be getting the error you are getting was if other process was also updating the sw_sequence object.

Hope it helps,

Cláudio