DFS.NET Checkout problem

Hi Experts

I have wierd problem and I wonder if anyone noticed the same. When I issue Checkout method of VersionControlService, field r_lock_machine in dm_sysobject is filled with name of application server (where DFS is runing) and not the name of machine where I did checkout. If I checkout document using other web application (e.g. webtop) everything is running as expected (r_lock_machine is really local machine where checkout is done). Is this known DFS bug, or I am doing something wrong?

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

PanfilovAB

Only if you have access to DFC layer (check this post: )

All comments

aflowers001

It's the expected behaviour I believe.

The DFS server runtime delegates to DFC to do the checkout, and DFC is running on the application server hence why that machine name goes into r_lock_machine.

ingbabic

So actually a bug is promoted to expected behaviour? How to explain to customers that this is expected? Technically you're right I suppose, but what we can do to remedy this situation? Then again if we think about webtop, how it could be that it is working, when DFC code is actually running on application server (not on client PC)?

aflowers001

I don't think the core webtop does anything with the lock machine, by default it stays as the web server. however dependant on the content transfer technology the database could be directly updated, such as UCF via ACS/BOCS doing the updates.

This could be done with DFS as well I guess, get the content then update the checkout machine - but then when you check in you'd have to change it to the DFS server such that it is able to actually do the check in operation.

DFC uses the lock machine as part of it's check around check in so it need to match. I do recall an issue we had whereby we had multiple DFS instances on different servers and had to put in a custom call to do check in that set the lock machine then did the actual check in. This may now be fixed in later revisions though. Probably needs a read of the the release notes :-).

Also logging a call with EMC will get a definitive answer.

ingbabic

Thanks for sugestion, but unfortunatelly it can't be done. If you try to update r_lock_machine you get:

[DM_API_E_UPDATE_BAD_ATTR]error: "The attribute 'r_lock_machine' is not updateable."

And by the way r_lock_machine is not used at all from any of content server, nor DFC, it's just an information to user. DFC on windows is using informations from registry of the local machine to check file back in. It's just unfortunate that information in r_lock_machine is wrong and even can't be updated. I hope that there is a tweak in DFS to somehow "persuade" it to write the correct information in.

I don't know how webtop is doing it, but it doing it correctly.

PanfilovAB



I don't know how webtop is doing it, but it doing it correctly.

What webtop version do you mean? I have been working with documentum since 5.3 version and had never seen behavior you described - r_lock_machine was always webtop hostname.


Thanks for sugestion, but unfortunatelly it can't be done. If you try to update r_lock_machine you get:
[DM_API_E_UPDATE_BAD_ATTR]error:  "The attribute 'r_lock_machine' is not updateable."

That can be fixed by overriding TBO doSetString() method:


@Override
protected void doSetString(String attributeName, int valueIndex,
        String value, Object[] extendedArgs) throws DfException {
    if (DfDocbaseConstants.R_LOCK_OWNER.equals(attributeName)) {
        setStringInternal(attributeName, value);
    } else {
        super.doSetString(attributeName, valueIndex, value, extendedArgs);
    }
}

aflowers001

or update via the view/table underneath, dm_sysobject_s if memory serves

ingbabic

I tested TBO on my test type and it's running (only I had to change the name of the attribute to r_lock_machine). Is there possibility to set TBO to dm_sysobject so that each object type in repository can have that behaviour?

ingbabic

It can be done if I register dm_sysobject_s as a registered table and give all users right to change. Without that it won't run. I wonder is it safe? Because then somehow I expose dm_sysobject to each and every user, all other attributes to change by the will. Or you meant something else?

PanfilovAB

Only if you have access to DFC layer (check this post: )

ingbabic

Well this works, thank you! I have Custom DFS service, where I put all things which I am missing in standard DFS, so I implemented it there.

At the and I must say that I still think (and you're right, it's true also for webtop) that this is a Documentum bug and what we are doing is just a workaround. If Documentum is able to deliver checked out file to local PC, it must be able to write that information in database and not to write the name of application server. It's just not right.