DM_OBJ_MGR_E_VERSION_MISMATCH when installing DAR

Recently, I had to script DAR installation for a bunch of DAR files as a part of an upgrade effort. The target repository version was 6.7 SP1. During DAR installation, I ran into the DM_OBJ_MGR_E_VERSION_MISMATCH error quite frequently. The message for this error looks like:

MSG: [DM_OBJ_MGR_E_VERSION_MISMATCH]error: “save of object xxxxxxx of type yyyyyy failed because of version mismatch: old version was zzz”;

When this error occurred, I got the same error even with dardeployer. I tried forcing full data dictionary publish and cache cleanup, but the error won’t go away. Eventually, I found a fruitful way to make the error go away consistently.

Each time the error occurred, bouncing the content server service for the repository got rid of the error.

Composer Project Install History (D6.5)

Recently, I got curious about the mapping for Documentum project artifacts to repository objects. While this post shed some light on the subject, I wanted to see it for myself. Another driver was that I had not done a DAR install, rather I had installed the project from Composer. Here is what I found.

There is a dmc_dar object, named the same as the Composer project. It is versioned with each repeated install of the same project to the repository. The content type of the object shows up as jar but in reality it is an XML file. When I tried to open it as an archive it indicated that the file was corrupt. I was able to view the XML by opening it in an editor. It showed the resolution map for artifacts to object IDs.

One thing I suspect based on the referenced post above is that if I installed a DAR then the DAR file will show up as the jar content (correctly). I will have to explicitly get to page 1 of the content to view the XML.

ACL, wait … Permission Set, no … ACL

Once upon a time there were ACLs (Access Control Lists) in Documentum. All the internal artifacts used the term. Then they were renamed to permission sets, though internal references continued to use ACL as expected. So both the terms were prevalent.

In version 6.5 the Content Server Fundamentals guide doesn’t even mention the term permission set. It seems to be all ACL again. But wait, Composer uses permission sets liberally.

Does it really matter? Probably not. Then why mess with the terminology repeatedly? I am sure that there are better ways to improve the platform.

Orphaned Java Method Server: 6.5 SP2 Windows-Oracle

While deploying DARs using Composer I started running into weird errors. The most common error was DM_SESSION_E_CLIENT_AUTHENTICATION_FAILURE. It was showing up across multiple clients.

Coincidentally, I had made a change to a lifecycle around that time and I got misled to believe that the lifecycle change caused the problem. After going down that path for several hours I ended up looking at the JBoss log. It indicated problems related to ports not being available.

So, I shut down all Documentum services and checked the ports. The ports 9080, etc. were still being used. I used netstat to look up the processes listening on ports using this command:
netstat -a -b -n

And I used Process Explorer to get the details by process ID. That confirmed that this particular java.exe was indeed running JBoss.

I killed the process and started the Documentum services again. Everything seems to be back to normal now.