nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Orphaned documents

subhajit4u

We have two Captiva Export Modules running in Production which runs parallelly. The Documents after getting imported into Documentum Repository calls a TBO to index it correct folders. Now if we run two parallel Captiva Export modules which export two documents who ultimately belong to the same folder in the CM repository then often it happens that the documents try to associate themeselves with folders which doesnt exist and thus get orphaned.

Please can anyone explain how to prevent this scenario?

Find more posts tagged with

Comments

PK4D

I am not sure I fully understood the scenario but I did understand that the folder that a document is trying to link to may be missing. One way to address this is to first check for the folder existence and create it if it doesn't exist. You can search for the already "orphaned" documents as the ones that have no folder ids.

RaviJha

Even if you check for folder existance before folder creation (I believe TBO would be doing it already), I can see potential race condition here.
So it should be important that you take care of synchronising the logic "which checks for existance of folder and creates folder".

I am guessing that such orphaning is possible if the TBO eats some exception.

Lets take a case when TBO for captiva module1 checks for existence first, it will get "doesnt exist". Say TBO for captiva module2 does the check before module1 could create it so it also gets "doesnt exist". Now if both of them try to create the folder, obviously the later call will bomb (with some exception like DM_XX_E_EXIST). In this case, depending on the execution pattern, one or both of the linking calls thereafter will not complete. But if you dont see an exception, definitely the TBO is eating it.

Even if my guess for the current scenario is incorrect, probably any future fix would need to be made bearing in mind the possible race condition I outlined.

I have no clue how captiva export modules and corresponding TBOs are loaded. If it is loaded by different classloaders, deeper thinking will be required on how to synchronize it.

HTH,

Ravi

agoodale

If you need a cross-JVM, cross-machine lock, you should look at IDfPersistentObject.lock(). It will cause a DB-level lock to block all threads without the lock. The thread with the lock can validate (and create) the shared folder. We've used this before to do things like implement a unique "auto-number" field, where you don't want multiple objects with the same value.

RaviJha

Good tip Andrew!

It will help if my theory holds water

Wiesnoepersad

Even when checking there can be sometimes that i can go wrongwhen running multiple threads.

When two folders with an identical value in r_folder_path are created inside concurrent transactions, the "save" API call will succeed for both folders since the server cannot detect that another folder with the same path has been saved in an uncommitted transaction. When the transactions are committed, the server performs a check to see if the folder that was created/modified in the transaction has a value in r_folder_path that is a duplicate of another folder. If it finds that this is the case, it deletes the folder. Hence whatever transaction is committed first will successfully create a folder. The folder created in the second transaction will be destroyed, and any objects linked to it will not be cleaned up.

agboan

Regarding Wiesnopersad, it is possible to create a unique index on r_folder_path (dm_folder_r table) if you have the fix available for CS-11707. This change is available in 6.5 SP1 content server, and will allow the creation of a unique index on r_folder_path that will allow you to error out if a duplicate in r_folder_path is detected.