ThinClient and checking editions: Has another user changed t

[ConvertFromOldNGs]

by Eric Peachey >> Mon, 4 Oct 1999 19:04:54 GMT

Hello,

Just wondering how you people approach the problem of identifying if another user has changed an object whilst you are currently editing it. In a fat client environment this was reasonably straightforward in that you could use the Object:::edition feature (and related methods) to see if the object in your cache was the latest edition before saving your updates. Assuming that each user would have their own 'node' and cache was probably a safe thing to assume (as the forms Wizard does) in a fat client environment. In the Jade Thin Client environment it's possible to have all your users sharing the same cache (i.e. that of the app server). So, what strategy would you use to detect that another user has changed an object that you are editing? Using notifications or cloning or storing details of the object concerned seem to be possible approaches.

Eric in Dunedin

[ConvertFromOldNGs]

by Craig Shearer >> Mon, 4 Oct 1999 19:44:14 GMT

Eric

In our systems we often use a specialised control for editing objects. This control takes care of locking objects etc. at the appropriate times, managing transactions etc. When an object is displayed it is share locked and we record the edition of the object at that point in time. Then, when the user goes to save changes to the database, we can check whether the edition of the object being saved is the same as the object that was share locked and thus detect the change at that point. This works fine on both fat client and thin client deployment options.

Another approach also used (which our control supports) is to have a notification on the object. When an object is updated, anyone currently editing the object gets a message box saying that another user has changed the object. They then have the option (configurable by the developer) of either backing out of their changes and viewing the latest edition of the object, or of continuing and eventually overwriting the other user's changes.

Hope this helps,
Craig.

[ConvertFromOldNGs]

by Krull >> Mon, 4 Oct 1999 22:19:01 GMT

In our systems we often use a specialised control for editing objects. This control takes care of locking objects etc. at the appropriate times, managing transactions etc. When an object is displayed it is share locked and we record the edition of the object at that point in time. Then, when the user goes to save changes to the database, we can check whether the edition of the object being saved is the same as the object that was share locked and thus detect the change at that point. This works fine on both fat client and thin client deployment options.

For straightforward inquiry/update scenarios I favour the approach described by Craig above. It is relatively simple, is not sensitive to cache distribution and doesn't exhibit timing holes. Don't forget to release the share lock in the inquiry transaction and in the update transaction (save), exclusive lock (not share lock) the object before checking the edition.

The use of Object::latestEdtition is problematic; I have seen examples of code that compare a saved object edition with latestEdition prior to an update, which can result in a lost update if two or more transactions do the same concurrently.

[ConvertFromOldNGs]

by Eric Peachey >> Mon, 4 Oct 1999 23:40:40 GMT

Hello,

Another developer has responded off list but thought it might be useful for others to see the approach described:

Quote

Our applications use the same form to view and edit an object. When the user wants to edit the object they click an edit button. This tries to place a share lock on the object which prevents any other users from editing
the object. When the user saves the object, the lock is raised to an exclusive lock, the details are then saved to the database and the locks released. If the user tries to edit an object that is locked they are informed that another user is editing that object. This method would prevent two users editing the same object.

EndQuote

Eric in Dunedin

[ConvertFromOldNGs]

by Krull >> Tue, 5 Oct 1999 0:14:38 GMT

Our applications use the same form to view and edit an object. When the user wants to edit the object they click an edit button. This tries to place a share lock on the object which prevents any other users from editing the object.

A share lock will not prevent two user performing the edit action; two or more users can acquire the
share lock concurrently, so you could have several users sitting in edit mode. Do you perhaps mean a reserve lock?

Assuming a reserve lock is acquired and held, is there a timeout mechanism that will release the lock if the user leaves the edit form up and goes off to lunch (you would need to arm a timer to accomplish this) or is it acceptable (for the business) to leave long duration locks on objects?

When the user saves the object, the lock is raised to an exclusive lock, the details are then saved to the database and the locks released.

Surely the lock in question was a reserve lock; if it was indeed a share lock, when two or more users own the share lock as soon as one of the users attempts to promote the share lock to exclusive they will encounter a deadlock exception!!!

[ConvertFromOldNGs]

by Torrie Moore >> Tue, 5 Oct 1999 1:44:07 GMT

You are right. We are using a reserve lock. We are not releasing the lock if the user leaves their machine. This is a good point as some users may leave their machines in Edit mode for a long time.

Torrie Moore