Object level locking for avoiding data overwriting

Dear experts,

We have forms implemented in Webtop that are using information from several objects. We perform form level locking to avoid two users simultaneously saving and overwriting each other's work, but in case the form is different, the disaster cannot be avoided. We need a second object level locking.

The scenario is:

Form A:

- Manages information of type A

Form B:

- Manages information of type B

- Manages information of type A

The forms are opened together by two different users or even from the same user in different tab. The Form A gets saved and then Form B gets saved. The results is that the information of content type A is overwritten and the changes performed in Form A are lost.

One solution would be to check the "i_vstamp" attribute of the type and allow the save operation only if it is the same with the one loaded by the form. Any other solution?

Panos

Find more posts tagged with

Documentum

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

Panos,

actually, your question sounds like "how to move locking technique (optimistic or pessimistic) from DFC layer to web?"

Checking i_vstamp is a good approach, but you should take into account following facts:

you should check it using dql query
it does not work in high concurrent environments (I don't think it's an issue in your case)
it performs bit awkward for end-user, i.e. user was editing form for a some time and on save he gets message "You know, data was changed, repeat all what you was doing before"

When I talk about checkout I just talk about writing some attribute value in persistent object. For example workitem is not sysobject too, but it has a_held_by attribute for the same purpose as yours.

All comments

PanfilovAB

Actually, the only solution is check whether objects to be edited are checked out or not, if yes check them out, if no display warning message.

PanosK

Can you check out/in persistent objects? I think it's only for sysobjects.

PanfilovAB

Panos,

actually, your question sounds like "how to move locking technique (optimistic or pessimistic) from DFC layer to web?"

Checking i_vstamp is a good approach, but you should take into account following facts:

you should check it using dql query
it does not work in high concurrent environments (I don't think it's an issue in your case)
it performs bit awkward for end-user, i.e. user was editing form for a some time and on save he gets message "You know, data was changed, repeat all what you was doing before"

PanosK

The problem of that is that you create permanent locking in case something goes wrong (server restart, crash). We are doing already something similar for the form level locking, but we keep the lock only for 5 minutes. It expires afterwards.

I think with the i_vstamp check solution, you can avoid that situation.

PanfilovAB

Yeah, there is no simple solution for web. For 2-tier applications your case is pretty simple: "select ... for update wait" - client tries to put database lock, if successful user continues to edit form, otherwise user gets warning, when transaction either commits or aborts it releases lock. In web you can't use such long-running transactions

Another way is create a singleton that will store list of ids of "locked" objects, and remove id on cancel and save actions, also you need to implement IHttpSessionManagerUnboundListener interface to remove locks if user logs out (you can find example of implementation in NewFolderContainer)

PanosK

We have followed the i_vstamp approach that is checked by the Component for all objects used and it has worked fine so far.