Visual LANSA Forum

Hi all,

We have implemented a VLF-WEB solution using LANSA V13 SP2 EPC132900 with VLF EPC132100.
We want to know if there is any locking mechanism in VLF-Web that will lock processing of an item to a specific user and inform the others that this item is currently locked.

As an example of what I am asking is the following.

A user wants to edit a client’s data.
He or she clicks on Edit Command Handler in order to edit the client data.
At this time a record in the db is inserted to hold the locking information.
Another user tries to edit the same client’s data.
By clicking on the Edit command handler, the VLF-Web checks if there is a record on the db that hold the locking information.
The VLF-WEB finds that record and informs the second user that he/she cannot edit client’s data as there are processed by another user and automatically disables the save button.
If the first user presses the cancel button the locking record is deleted form the db and therefore the client’s data are available for edit by another user.

Up to this point, the locking mechanism can be easily constructed.
The questions arise in the following situation.

When the first user, who is editing the client’s data, decides to change command or even to close the VLF-WEB application, how VLF-Web is going to understand that the user is leaving the Edit Command Handler, who has already locked the clients data, and inform him/her that he/she is in edit mode?
If the user accepts the message and decides to leave without saving the changes or cancel the edit, how VLF-Web is going to delete the locking record in db?

Is in VLF-WEB some mechanism that:
i. Will understand if the user changed Command Handler (some kind of focusOut() from the command Handler)
ii. Will interact with the db without that being via user interaction (e.g. press of a button)

Are you aware of any locking mechanism that has been developed by any of LANSA partners?

Thanks in advance for your answers.

The root of this general web browser problem is that WAMs, like all server side web software, work best when they are designed to be stateless. http://docs.lansa.com/14/en/lansa051/in ... 8_1730.htm

If you want to ignore that and do some soft locking, then LANSA supplies lock_object and unlock_object built in functions:
http://docs.lansa.com/14/en/lansa015/in ... object.htm
http://docs.lansa.com/14/en/lansa015/in ... object.htm

That means you can probably do what you need in your code - structurally locking and unlocking as you move around - with quite a few unlock *ALL operations in key points such as when every new business object filter or command handlers starts.
If you put an “Exit/Log Off” button on your tool bar, then it can also do an *ALL unlock for any locks left hanging around for the user.

The problem with this is that some users will not do that and instead just close the browser window.
That’s where it gets complicated because browsers don’t tend to reliably allow you to send any more HTTP requests when they are closing. They do and they don’t, so if it works for you once don't assume it will always work, it is not reliable in my experience. So, make sure you create some sort of manual lock releasing function for you administrators to use when stuff gets left locked by lazy users.

The other way to do this might be to play the odds. How often do problematic locking situations occur? If it’s not much, then you can use a cross update check. Say you WAM updates someone’s address details. You snapshot those values when you first display them. On update you reread them and compare them to what you snapshotted. If they are different you reject the update and apologize saying that someone else changed them while you were reviewing/changing them – you might even be able to name that person.