Record Lock need a Locked Map?

[jin Young]

Hi all ranches.
I am sorry for asking a junior question in advance.

I searched the archive topics,and found that most lock implementation is :
synchronize access the data file, also maintain a Locked Map which contains locked records.

I thought, it is not necessary. if the data file is accessing synchronized,the "locked map" still required?

Thanks in advance!!any response would be appreciated.

[Justin Rundle]

Hi Jin,

Your design should decouple the functionality as much as possible, in saying that the locking logic should be totally seperated the data acces layer (DAL). The major advantages is that other components can re-use your DAL without the locking impl. and visa versa other components can use the locking impl. without the DAL interferring?!

More so with that said if seperate the locking logic out of the DAL how would maintain state of which records are locking without some sort of collection.

hmmm... something to think about?!

[Roberto Perillo]

I am sorry for asking a junior question in advance.

We're always glad to at least try to help

The Map is the structure where you can keep the locked records. For instance, in my case, I have a HashMap where the locked record is the key, and the client is the value. Even though you have a synchronized access to the data file, you still have to implement the locking mechanism, because, for instance, if two clients try to update a record at the same time, without the locking mechanism, both of them will get a "Record updated successfully" message, but one of them overwrote the other client's data. So that's why the locking mechanism is required. The Map structure is where you can control which record each client has the right to either delete or update. But if you can think of another structure to control this correctly, than it should be ok.
[ December 04, 2008: Message edited by: Roberto Perillo ]

[jin Young]

Justin & Roberto , Thanks for you quick and great response.

I come to realize the reason why need the map.
about locking, I still can not understand the requirement clearly for this test, would some one demonstrate it? thanks.
I run the Denny's DVD sampleproject. For example,now there 8 copies in stock whick UPC is 123456789
12:01 client A to a server.
12:02 client A to a server.
now time is 12:10.
Client A press ReturnDVD button the copies is 9.
then Client B press RentDVD button the copies is 8.

It seem the locking does not work?
Or this is OK,the locking is just to permit one client do some job where several client press the SAME BUTTON at the SAME TIME?

thanks again.

[jin Young]

as scenario described previous.
Client B is not recieved the locking error, and update sucessfully, also the data update correctly.
is that ok?
Thakns a lot.

[Roberto Perillo]

The locking mechanism is supposed to work in the following scenario:

Client A tries to lock record 1
Client B tries to lock record 1
Client A locks record 1
Client B is waiting to get record 1. Here, the Thread gives up the CPU (wait())
Client A updates record 1
Client A unlocks record 1 and notify all clients that are waiting for it
Client B wakes up
Client B tries to lock record 1
Client B locks record 1
Client B updates record 1
Client B unlocks record 1 and notify all clients that are waiting for it

That's it.

Tip 1: always, whenever you acquire the lock of a record, be sure that it still exists. Do not forget that you also have to acquire the lock of a record to delete it, so it's not guaranteed that when you acquire the lock of a record, it still exists!
Tip 2: even though in standalone mode you wouldn't have to deal with concurrency, your locking mechanism MUST work properly in both standalone and networked mode.

[jin Young]

Hi,Roberto. Great thanks for your detailed reply.

thanks.