I figured I’d add a bit to his post… When you edit/view content using a Documentum client like Webtop (any client that uses DFC or UCF) an entry is made in a client side “database” that is referred to as the client registry. This entry indicates the file system location of the document(s), the associated object id, the date/time the content was pulled out of Documentum and a few other housekeeping items. If you checkout an xml file that is managed by an xml application that has supporting documents, these files will also be referenced in the registry. If you are working with virtual docs and you pull all referenced content then entries of all referenced content will be created.
The client registry appears to be used for several things. First and foremost it supports optimizations where you try and checkout a document that has already been checked out. Documentum can simply return the local file rather than transferring bits over the wire. By associating an object id with a file system path, the client registry allows DFC/UCF to remove local copies of files when you check the content back into the docbase. Similarly the client registry provides a mechanism so that DFC/UCF can clean up content that has been hanging around for a long time.
As Laurence says in his blog, on Windows, the default storage mechanism for the client registry is a key in the Windows Registry (the OS provided read-optimized database that many applications use to store configuration information.) In order to work on non-Windows systems, Documentum has also implemented a storage model that uses an ini file (called documentum.ini).
Now for my rant :) While the Windows Registry is optimized for Read, it is quite slow for writing. The ini file model is bad both for reading and writing. We recently captured profiliing data for a webtop customization (where checkouts/checkins were performed on the app server) and discovered that a large documentum.ini file (> 60k lines) was causing a concerning amount of performance degradation. DFC appears to be parsing the full ini file for each check in/out operation in some kind of synchronized code section.
A plee for enhancement from Documentum: please implement the client registry using a technology that is optimized for both read and write (as this appears to be your usage pattern.) I would suggest something like SQLite or Berkeley DB which I believe both have zero config java db implementations that can be packaged directly into DFC. This should also improve stability (we have seen the error Laurence refers to with DFC failing to bind to the Windows Registry access code, and a restart would solve the problem, going with a 100% java solution would mitigate this binding issue.)
And a little note about working around this. If you are using DFC operations to perform check outs/ins, there is a method call on the operation object that allows you to bypass the client registry altogether. For server side code, this may require a little extra effort in development, but you will benefit from improved performance and reliability. I’m less inclined to do this for client side code, but if you are so motivated, it wouldn’t be all that hard to write your own client registry using something like one of the above mentioned java databases.