implement data concurrency

[Ivy Kho]

hi! i'm a java newbie and i've been tasked to create this web application. my question is what's good way / strategy to implement data concurrency?

for data concurrency, my officemate suggested this design :
if user A is editing a record in the table then that record should be locked from other users. A class, called UserAccessRightsManager, will supervise all the locked records. So, if user B wishes to edit that record, he must go through UserAccessRightsManager. Is this a good idea? If not, can you give some suggestions? I'm a bit worried with his idea. What if two users edit the same record at the same time?

would appreciate any help! thanks!

[Ray Stojonic]

That's the point of the UserAccessRightsManager, if record A is found to be checked out by user A, then user B is told 'sorry, it's in use, would you like to view it in read-only mode instead?' by the UserAccessRightsManager.

[Tad Dicks]

Unfortunately from what I understand thats difficult to implement in a web application. Its to easy for someone to exit the application or get disconnected with out giving up the lock when they're finished. I suppose you could run timers that times people out, but that seems like a lot of work. One way to work around this is do the read w/o checking anything when the user does a write back to the database make sure the record there is equal to the record he read. If it is commit the changes, if not give him a message that the data has changed (refresh his read with the new data).

Another question to ask is what actually will happen when two people edit the data? Is this a resource that *needs* to be locked down, think of a limited number of airplane tickets being sold, where it would be really bad if agent one reads 355 tix left and sells 4 tix (writing back 351) while agent 2 sells 1 ticket(reading 355) and writes back 354 when their should really only be 350 tix left.

Now consider two people editing the same description of a widget being sold online. What happens? who ever writes second will have their edits go into effect (not exactly disastrous, and possibly the desired outcome).

If your data resources are more similiar to the second circumstance, ask is it worth it to write something to manage the concurrency issues?


-Tad

[Stan James]

We often use the terms optimistic and pessimistic locking. There are many ways to implement each, but let's look at a couple.

In pessimistic locking you want to prevent the second person from getting the lock. Your lock manager does that job. The risks are that the first person never releases the lock, or never really meant to update it so the whole locking process was wasted. Databases implement this, too, with read for update. Same risks.

In optimistic locking you think the odds of two people editing the same data are low enough that you won't lock the record, but check at save time to see if has been updated or not. We often do that with timestamps. When you get a record you get the last update timestamp. Before you update it you check to see that the timestamp is still the same. If not, tell the user "Sorry, somebody else changed it, you must retrieve and edit again." In a database you can add a where clause to your update statement. In Java code you probably want to synchronize some or all of the logic. This is also known as "first in wins" because the first person to save succeeds, even if he was not first to retrieve.

I just bought some concert tickets at TicketMaster. I hit the "best available seats" button, and it showed me two seats. I had two minutes to commit before they put the seats back in the pool. I bet that was a fun problem to solve!

Zat help?
[ February 15, 2005: Message edited by: Stan James ]