aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking strategy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Locking strategy" Watch "Locking strategy" New topic
Author

Locking strategy

David Winters Junior
Ranch Hand

Joined: Oct 30, 2007
Posts: 47
Hi All,

Im currently on the locking part of the assignment (UrlyBird 1.3.1) and i was wondering how others completed their locking strategy.

1.In the DBMain interface there are 3 lock methods: lock(int recNo),unlock(int recNo) and isLocked(int recNo) however i do not wish to use these 3 methods but i would rather delegate this to a seperate Locking class. Is this okay not to implement these methods? What have others done here?

2. I have seen others on here storing the current thread object to determine which client has the current lock however since i am using rmi as my networking implementation then this would seem flawed as threads can be reused in rmi by different clients? For my locking strategy should i not just store in a Map the key of the file being modified along with the actual Booking object here so anyone else wishing to change this record will check the Map and if it is in the Map then this client will have to wait until this entry is removed from the Map?

All thoughts very much appreciated
David
uzma ali
Ranch Hand

Joined: Jun 22, 2007
Posts: 56
I can only give you the answer to your first part
YOu might have known about Facade Pattren. Create a class which implements all the methods from DBMain in the the Facade at least give a body and then you can have differnt classes for detailed implementation.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

Originally posted by David Winters Junior:
1.In the DBMain interface there are 3 lock methods: lock(int recNo),unlock(int recNo) and isLocked(int recNo) however i do not wish to use these 3 methods but i would rather delegate this to a seperate Locking class. Is this okay not to implement these methods? What have others done here?


You need to implement all methods for sure. It's probably the biggest part of SUN's assignment. And then, after that, your GUI/Client only use a part of it.


2. I have seen others on here storing the current thread object to determine which client has the current lock however since i am using rmi as my networking implementation then this would seem flawed as threads can be reused in rmi by different clients?

I store the thread Id on the basis that a client has to perform a complete "lock - operation - unlock" cycle during the same "transaction".


For my locking strategy should i not just store in a Map the key of the file being modified along with the actual Booking object here so anyone else wishing to change this record will check the Map and if it is in the Map then this client will have to wait until this entry is removed from the Map?

I'm not sure what's the booking object you are refering too. Some assignments have to handle a "cookie" which allow them to use it as an uniqueId for locking. I do no have any cookie in the signature of my Data Interface.
If you are not refering to the "Cookie", then think again how you could decide if the current executing client checking in the Map is really the owner of the lock.

good luck.

Regards,
Alex
[ November 27, 2007: Message edited by: Alex Belisle Turcot ]
David Winters Junior
Ranch Hand

Joined: Oct 30, 2007
Posts: 47
Thanks Uzma and Alex for your replies.

Uzma i agree that i should implement them however dont wish to place any locking code inside of these methods i wish to allow my business class to do the Locking or call the LockManager class to lock various files.

So i have say a Business class which essntially wraps the methods in the Data class which i tyhink you are referring to as a facade class and its within the facade class that i call the methods reserveLock() and releaseLock().

Alex

I am just wondering as to why you need to store the thread id of the client.In RMI threads can be reused so using this as an identifier for the client does not seem to be plausible or perhaps im missing something here. Also we shouldnt really call our lock/unlock methods from the client i believe these should be handled by the business class via a seperate LockManager class. So a client wishes to update a record, he calls update and then in the business/facade class we call checklock->lock-update-unlock in this sequence here.

David
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Originally posted by David Winters Junior:
I am just wondering as to why you need to store the thread id of the client.In RMI threads can be reused so using this as an identifier for the client does not seem to be plausible or perhaps im missing something here. Also we shouldnt really call our lock/unlock methods from the client i believe these should be handled by the business class via a seperate LockManager class. So a client wishes to update a record, he calls update and then in the business/facade class we call checklock->lock-update-unlock in this sequence here.

Hi,
First, I'm not saying you NEED to, it's how I do it..
Also, in my design, the client does not do "lock-unlock", he does the business operation, which on the server side, will do lock-operation-unlock. This is a design decision and because of that one constraint is that the "lock-operation-unlock" must be done in a single transaction (for me). meaning, from a single method call from the client, on the server side I will do lock-update-unlock.

Because the whole cycle is handled within one transaction (1 thread on the server side), I can uniquely identify the "client" with the thread id. Other than that, I don't know, maybe the customer Id could help you identify the client across multiple RMI call.

Regard,
Alex
David Winters Junior
Ranch Hand

Joined: Oct 30, 2007
Posts: 47
ok thanks alex that makes sense but more thing as to why we need to identify the client at all here or what is the gains in doing so and storing it here. I mean if i have stored in a Map the current record being modified its primary key and the object we iwhs to modify the recrod with and the Map is static then i dont see the point in stroing the thread id.

So if i had the following scenario without a thread id in use:
client 1 -> thread 1 who calls update on record 1 -> check lock - lock free ->lock on rec 1

client 2- thread 1 who calls update on record 1 - _> check lock ->lock not free -> wait

I guess my question is why we need to identify the client at all duirng locking?

David
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Originally posted by David Winters Junior:
I guess my question is why we need to identify the client at all duirng locking?


A little late to reply, I missed it completely..

You need to know which client has the lock, to make sure that only this client will be allowed to update/delete a record.. Which is the purpose of locking the record.

If you don't identify the client, then your update/delete got no way to check if the "caller" is the "owner" of the record:
1. Bob locks record 2.
2. Alice tries to update record 2.
3. Alice is not the client owning record 2, the operation is rejected.
4. Bob tries to update record 2.
5. Bob is the "owner" of the record and the operation is successful.

Regards,
Alex
 
 
subject: Locking strategy