Content Server and DMCL

February 19, 2007 at 2:36 pm | Posted in Architecture, Troubleshooting | 4 Comments

The poor old Documentum Client Library (DMCL) gets blamed for a lot of things. The suggestion to delete the dmcl cache to avoid a multitude of problems has now entered the realm of myth. I’m sure that for many problems this is the correct solution. However, as you will need to shutdown the application using DMCL before deleting the cache, in many cases the simple act of restarting the application may have resolved the problem anyway. Still, since you can never be sure, a quick delete of the cache is no big deal if you are going to restart an application anyway.

However the finger of blame sometimes gets pointed at the DMCL even when it is unlikely to have any connection with the problem in hand. An example is internal processing failures of the Content Server process. I have seen people (including Documentum support) suggest dmcl cache clearing even for problems that arise inside Content Server processes. One of the keys to troubleshooting is using an understanding of how applications are architected to rule out certain explanations for the error.

The figure below shows a typical Documentum technology stack. This particular example is for a web browser accessing WebPublisher but you will see a similar picture for other client applications. The key here is that DMCL is a client library. Content Server exposes all its functionality via a set of (undocumented) server functions that are accessed via a Remote Procedure Call (RPC).

Documentum Technology Stack

The DMCL is a linked library inside the client application – a DLL in windows, shared library in Unix. The DMCL takes documented API calls made by the client application and maps them to Server RPC functions that can be executed by the Content Server. Once the call has arrived inside the Content Server process the processing is no longer affected by the DMCL environment. In fact the DMCL thread that made the call will simply be sleeping awaiting the results of the processing from the server.

The really confusing part is that DMCL is included with the Content Server installation. The reason is that much of the functionality that is associated with the Content Server is actually implemented in external methods. In these cases the external method is a client of the Content Server and will utilise DMCL (via the API) to do its work. So really you need to be clear where the error is originating from. Does it arise from the external method code or does it arise from processing inside the content server?


RSS feed for comments on this post. TrackBack URI

  1. how do you clear the docbase cache? is is the whole dmcl directory or just a certain (like qrycache) directory under that?


  2. The simple answer is delete the dcml directory.

    In fact dmcl is just the default location for the dmcl cache if you don’t specify a local_path entry in the dmcl.ini. If you have got local_path defined then you will get a number of cache directories under the local_path directory: object_caches, qrycache and type_caches plus a directory for each docbase you access (named with the docbase id).

    • Hi,

      I know that I’m digging up this topic but I have a question about the Documentum cache management.
      You’re speaking of directories for each docbase which is accessed: do you know what they are for?

      Thanks a lot !

  3. […] pattern involving both DMCL and DFC on the Content Server. Perhaps it is best to refer to my description of the Communication Pattern. However this was the only significant error I […]

Leave a Reply

Please log in using one of these methods to post your comment: Logo

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

Create a free website or blog at
Entries and comments feeds.

%d bloggers like this: