A bit about the DFC Client Registry

Laurence Hart, in his blog Word of Pie, recently posted this entry about the DFC Client Registry:
Tips: Watch the DFC Registry Mode

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.

Tags: , , , , , ,

3 thoughts on “A bit about the DFC Client Registry

  1. Good Post.

    To Add further to this, the Registry is used for optimization in View mode only. I don’t think it does optimize during Checkout/Export. It stills transfers the content over the wire to the WDK based clients during Export operation (overwrites the existing content with a prompt) and the Checkout Operation creates a _no.<extn if the file already exists in the checkout directory due to some exceptional behavior and was need removed during cancel checkout operation. This applies to UCF and DFC.
    The “Optimization in View” mode on the WDK based clients is done based on the following parameters. checksum, format & vstamp.
    Checksum is based on the following algorithm.
    Calculate the local viewed file’s checksum (physical file) and compare it with the already recorded checksum value in the registry(this is calculated and recorded when the file is viewed for the first time).
    So if the above match the local file is Launched without any transfer.
    The Registry records “Viewed Files’, “Working Files” (checked out files). Exported Files are not recorded in the registry (not sure why?).
    Any linked files of a checkout/Export operation go into InlineDescendents registry entry.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s