Long lived locks

[aaime]

I'm writing a rich client and I'm facing the need for a long lived lock, that is, a lock that disallows data editing as long as the user is in a certain screen, because the effects of two user eding the same data would be disastrous (the screen in a data flow graph editor).

Since services are stateless, I'm wondering, how do you manage long lived lock? With an application level table that lists the ID's of the lock object and an expiry date?

[adepue]

We came head to head with this as well. Off the top of my head, here are some solutions we toyed with:

• An actual locking mechanism, whereby you can specify a portion of data that is locked, and other users will either block or error if they attempt to access the data.
• Batch datasets and merging. This is where the client loads an entire dataset, makes changes, and then submits the changes to the server (when the user clicks "Save", for example). In order for this to work, you either have to employ locking, as above, or handle merging various user's changes at save time.
• Live distributed models. Similar in idea to Tangosol's Coherence, the client will keep a local copy (cache) of the dataset (or model), but the local copy is updated live via distributed events/messaging. Whenever any client updates the model in any way, the update will be distributed to the server immediately, where the server will persist the change and then distribute the update to all clients. If a user in NY changes something, then the user in CA will immediately see the change in their UI. Of course, there are various levels of locking and synchroneity you can employ here, but the basic idea remains the same.

There are other approaches, but these are off the top of my head. Each one of these have their place. For us, the last option fit our needs best, which is what we ended up implementing (primarily via ActiveMQ).

- Andy

[aaime]

Unfortunately the messaging solution does not fit very well with my application. The main problem is, it's a graphical editor with undo/redo.
Most of the information is edited in memory and will be saved only at the end of the editing, and this creates no problem, since the graph is versioned (so, two users editing the same graph will end up creating two subsequent versions of the graph, no much harm).
But some information used by the graph is shared (things like classifications of the graph nodes). This means, once a modification of the shared knowledge is done, I have to lock that row since otherwise another user could interfere with the undo/redo mechanism...

[scottr]

Since services are stateless, I'm wondering, how do you manage long lived lock? With an application level table that lists the ID's of the lock object and an expiry date?

I think this is probably the best way to go. I am facing a similar situation in my company, where db-level locking of records during screen edits leads to horrible problems later on.

Unfortunately, because databases don't support long transactions inherently, you need to roll your own leasing mechanism and ensure that all applications respect the integrity of the lease. And the expiry date of course helps to prevent stale leases. I find this is the best option when you have the possibility of multiple applications running in different JVMs potentially accessing the database, yet you don't want to resort to db locks for reserving data.

-Scott