DM_FOLDER_E_CONCUR_LINK_OPERATION_FAILURE

It seems that Content Server 7.2 got a new weird behavior – now if you perform create/update/delete operations with dm_folder objects in transaction you may get one of DM_FOLDER_E_CONCUR_LINK_OPERATION_FAILURE, DM_FOLDER_E_CONCUR_UNLINK_OPERATION_FAILURE or DM_FOLDER_E_CONCUR_RENAME_OPERATION_FAILURE error:

--
-- Session #1
--
API> begintran,c,
...
OK
API> create,c,dm_folder
...
0b024be98000a900
API> set,c,l,object_name
SET> folder 1
...
OK
API> save,c,l
...
OK

--
-- Session #2
--
API> begintran,c,
...
OK
API> create,c,dm_folder
...
0b024be98000a90b
API> set,c,l,object_name
SET> folder 2
...
OK
API> save,c,l
...
-- 10 sec timeout
[DM_FOLDER_E_CONCUR_LINK_OPERATION_FAILURE]error:  
      "Cannot perfrom the link operation on folder (0b024be98000a90b), 
      as some concurrent operation is being performed on the folder or 
      decendant folder or ancesstor folder with folder id 0c024be980000105."


API> commit,c,
...
[DM_SESSION_E_TRANSACTION_ERROR]error:  
      "Transaction invalid due to errors, please abort transaction."

it seems that new behavior originates from following bugs/CRs addressed in 7.2 (check release notes):

Issue Number Description
CS-46175 r_link_cnt on folder is not showing the correct numbers of objects held by the folder.
CS-40838 When two users perform a move operation of two folders simultaneously, the r_folder_path and i_ancestor_id parameters contain incorrect values causing folder inconsistencies in Oracle and SQL Server. Workaround: Add disable_folder_synchronization = T in the server.ini file. By default, the value is F.

The interesting thing here is a fact, that new behavior has nothing in common with consistency – EMC developers are not familiar with the common lock pattern:

  if (condition) {
    acquire lock
    if (condition) {
      do work
    }
    release lock
  }

and make mistakes that even junior developers do not make:

--
-- Session #1
--
API> create,c,dm_folder
...
0b024be98000c2dc
API> set,c,l,object_name
SET> test_folder
...
OK
API> link,c,l,/dmadmin
...
OK
API> link,c,l,/Temp
...
OK
API> link,c,l,/System
...
OK
API> save,c,l
...
OK

--
-- Session #2
--
API> begintran,c,
...
OK
API> create,c,dm_folder
...
0b024be98000c2e8
API> set,c,l,object_name
SET> f1
...
OK
API> link,c,l,/dmadmin/test_folder
...
OK
API> save,c,l
...
OK

--
-- Session #1
--
API> destroy,c,l
... waiting

--
-- Session #2
--
API> commit,c,
...
OK

--
-- Session #1
-- 
OK

--
-- Session #2
-- here we get zombie folder
--
API> get,c,0b024be98000c2e8,r_folder_path[0]
...
/dmadmin/test_folder/f1
API> retrieve,c,dm_folder where any r_folder_path='/dmadmin/test_folder'
...
[DM_API_E_NO_MATCH]error:  
    "There was no match in the docbase for the qualification: 
    dm_folder where any r_folder_path='/dmadmin/test_folder'"

What a shame!

3 thoughts on “DM_FOLDER_E_CONCUR_LINK_OPERATION_FAILURE

  1. This is actually from 7.1 P02 onwards. It is caused by a new flag (set to False by default). The flag is disable_folder_synchronization and you set it to T to turn it off. DO NOT DO THIS – UNDER ANY CIRCUMSTANCES.

    Like

  2. That’s ridiculous. Folder inconsistencies exist in Content Server since the initial version, and all wise developers do know about this weird behaviour. Restricting creating subfolders in transaction just to make r_link_cnt attribute consistent is a total bullshit (from user perspective this attribute is never consistent due to access permissions).

    Like

  3. Well it is turned OFF by default and this is why you’re seeing this new behaviour. It has certainly caught us out recently. We have a support case with engineering due to an issue that occurs when we disable folder synchronisation – which is what we have to do in order to create transactionally safe case structures concurrently linked to the same parent,

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s