How to expire locks.

[ghanshyam sharma]

Hi guys.
How do you guys manage lock expiration. If a client goes down after locking a record, the record should expire after a given time period I guess ?
I am planning to store a timestamp in the lock and whenever a given lock is old enough clean it up. Do you guys have a silent thread working in the back ground, cleaning locks or something like that ???
I would appreciate if you guys can throw in some ideas here.
Thanks Already.
-Sharma

[Mark Spritzler]

There are two solutions out there that people use.
Max has his heart set on the WeakHashMap, and the cooler people, with hair, prefer using the Unreferenced interface.

Mark

[Andrew Monkhouse]

Hey! I also choose the smooth head look, and the Unreferenced interface.

[Max Habibi]

ouch!
M

[ghanshyam sharma]

Hmm, is there a way to controll the time intervals for lock expiration using WeakHashMaps ??? Unreferences Interfaces wont be usable for some of the requirement specifications out there ...I dont think there are though...
-Sharma

[Andrew Monkhouse]

Hi Sharma,
What requirement do you see stopping you from using Unreferenced?
I don't think you can change the time intervals for when your WeakHashMap will be swept. But there is no requirement for a quick release of locks owned by dead clients. (There is not even a requirement for any release of locks owned by dead clients ).
Regards, Andrew

[Philippe Maquet]

Hi Andrew,
I confirm there is no notion of any time interval in a WeakHashMap. But once an object stored in it becomes weakly reachable, it's cleared very fast.

But there is no requirement for a quick release of locks owned by dead clients. (There is not even a requirement for any release of locks owned by dead clients).

Right. But if you impelement such a release, as Unreferenced may be called after minutes (or even tenths of them by default as far as I know), it is not very nice for remaining clients to have locks owned by dead clients for so much time. Remember that there is no timeout in lock(), so they will hang. OK it is unprobable that they will try to lock the same records as the dead client. But I think of a more probable bad scenario (I am unsure of it) : when a client crashes, there is 95% chances that the user will reconnect immediately. For what to do ? To perform the job he was doing when he crashed, meaning working on exactly the same record(s) ... and entering in deadlock with himself for at least a few minutes. Is this scenario possible IYO ? If yes, it shouldn't be much appreciated by the user, right ?
Best,
Phil.

[Andrew Monkhouse]

Hi Philippe,
Thanks for the conformation on setting time intervals for WeakHashMaps.
You are 100% right for a real world project.
But for this assignment, it can be argued that this is overkill. So many people get very good marks without going down the path that you and I have followed. There was one person last week who got 100% for locking and server design without doing anything to handle dead locks or dead clients.
Regards, Andrew

[ghanshyam sharma]

Hmm tell me if I have trudged into some unknown area here but here it goes
In my implementation, and somewhat required by the Requirement Specification, [as i understand] My server does not keep track of the clients directly. (Whatever that means). When the client acquires a lock, he gets a UUID type of a cookie in return, which he requires to use to modify/unlock that particular record, as long as some clients comes up with the right record number and the identification cookie, he is a valid [should I say not dead/Alive !!!] client....
So I have no way but to build a server centric, timestamp based lock expiration strategy. I also keep timeout setting in a prioerties file so the Customer can adjust lock timeouts as per his requirements. A value of say 30 seconds is not going to hurt the clients who have something like a power breakdown I guess...Offcourse lost connections are different beasts and I dont think I should think so much about them....
Frankly I am trying to have some fun here while I finish this assignment
Thanks guys.
-sharma

[Andrew Monkhouse]

Hi Sharma,

In my implementation, and somewhat required by the Requirement Specification, [as i understand] My server does not keep track of the clients directly. (Whatever that means). When the client acquires a lock, he gets a UUID type of a cookie

Sounds reasonable.
Just a quick comment on the "required by the Requirement Specification" though - not all specifications are the same. For each assignment category (airline, hotel, contractors) there are multiple versions, each with little differences. Some know differences are that some versions require you to use cookies, some do not allow cookies. Some use a byte in the database meta data to indicate how long a field is, some use a short. So your requirements are just that: yours. Someone else, apparently doing the same assignment as you, can have totally different requirements. So if you see a topic being discussed that doesnt make sense to you, it doesnt necessarily mean that you or they are wrong - it could just be that they are discussing different requirements.

I also keep timeout setting in a prioerties file so the Customer can adjust lock timeouts as per his requirements.

Do you have a GUI for the server where this can be set?
What happens if a client locks a record, delays more than your timeout value, and then tries to update the record? Do they get a SecurityException? Do you document (both in API docs and in your design docs) that this happens?
[OT] You got SCEA before going for SCJD? Are you trying to have a backwards career?
Regards, Andrew