• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

pls validate my locking strategy - all inputs are g8ly appreciated. (URLyBird)

 
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all:

i have the locking implemented and posted some pseudo code snippets and the approach taken.
please give your valuable comments. Andrew and all your input is greatly appreciated.

Regards.
Steve.

Approach was
1. define a max wait time cycle and transaction time out. This will avoid any deadlock possibility and self recovery as well.
2. my mLockedRecords Map contains the recno and the the Thread.currentThread() Thread instance value. This i am using to identify the unique ClientID. i use this in lock and unlock methods to wait or notify calls appropriately.
3. according to the instructions, the update and delete must be mutex, so i have synchronized block on the DeletedRecords array list that holds the deleted records and then with in the block check if not deleted, lock, perform delete or update logic, finally unlock.
4. all locking code is implemented in lockmanager class

pseudo code snippets
---------------------
1. delete method (not synchronized)



2. update method (not synchronized)



3. lock method (not synchronized)
mLockedRecordNos is a Map with key as recordNo and value is Thread.CurrentThread() instance. If txn time exceeded then throw runtime Exception DatabaseServerException with out locking or continuing the method.


4. unlock


[ December 01, 2005: Message edited by: steve mcdonald ]

[ December 01, 2005: Message edited by: steve mcdonald ]
[ December 01, 2005: Message edited by: steve mcdonald ]
 
steve mcdonald
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ofcourse my
create method : not synchronized has the
Atomic operation with


[ December 01, 2005: Message edited by: steve mcdonald ]
[ December 01, 2005: Message edited by: steve mcdonald ]
 
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Steve

We are in the same boat, I have URLyBird 1.3.3 you may take a look on :


[url=https://coderanch.com/t/187701/java-developer-SCJD/certification/lock-mechanism-correct]https://coderanch.com/t/187701/java-developer-SCJD/certification/lock-mechanism-correct



There I expose some parts of my lock manager.

Ok now lets start:


1. define a max wait time cycle and transaction time out. This will avoid any deadlock possibility and self recovery as well.



In my spec is nothig about a time out. I try to prevent the deadlock by metodolody. IMHO to prevent is better than to recover.


2. my mLockedRecords Map contains the recno and the the Thread.currentThread() Thread instance value. This i am using to identify the unique ClientID. i use this in lock and unlock methods to wait or notify calls appropriately.



If you choose RMI you can not use the therad like unique ClientID. There is no guratee that two call on the same remote object will be done in(with) the same thread.

Now about the code sniplets :

1.How you prevent the usage of unlocked records - let's that a slappy programmer wrote a new client (front end) and he use the delete, update without to lock them first.. How you slove this.

2. I don't know your design but this your Data class why you use the unlock with delete, lock and other methods ? The unlock method is part of the API, you must let the user(the client) to decide when to lock and when to unlock.

3. Now about the timeout (as I said), I think (and thats only my opinion) that the time out is a little bit agains/over the specification(at least over my specs). On the other side is hard to find the perfect value for time out because you don't know how long can take a read/write operation.

I hope this will help.

Regards,
Mihai
[ December 01, 2005: Message edited by: Mihai Radulescu ]
 
Ranch Hand
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello steve
Could you put your code snippets between [code][/code] tags?
And remember that many of us don't recognize abbreviations.
Regards
 
steve mcdonald
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mihai
thanks for the comments. Here is my understanding

If you choose RMI you can not use the therad like unique ClientID. There is no guratee that two call on the same remote object will be done in(with) the same thread.

Are we taking session management across multiple requests when the client is alive, with cookies or some identity etc., ? I don't see a requirement for UI from sun, to perform a lock on selected row, then user takes own time and do whatever and he/she hits performs operations on the selected locked row and the release ?

To make things simple. A selection from the UI, (is only at the UI as a marker, involves no round trip to the server) and as soon as the user presses book, then it is an atomic operation via RMI -> calling the dataclass and then delete/create/update operations on the record. So i believe it is guaranteed that a unique thread is assigned for each atomic concurrent client request ? right or wrong ?

Now about the code sniplets :

1.How you prevent the usage of unlocked records - let's that a slappy programmer wrote a new client (front end) and he use the delete, update without to lock them first.. How you slove this.

All the delete/update are atomic operations perform lock/unlock with in the method call, which eliminates the lame user/programmer to perform lock/ unlock as separate operations, though they could do. if wanted as it is available on the api. May be my understanding is wrong. the Lock/Unlock are public and exposed for a reason to use :-),




2. I don't know your design but this your Data class why you use the unlock with delete, lock and other methods ? The unlock method is part of the API, you must let the user(the client) to decide when to lock and when to unlock.

Although i didnot do the UI yet, but here's what the user work flow i thought about.
- A user gets a list of records, all or by criteria.
- selects a record (one and only record for each request is supported). This selection is just a market on UI to track the record being worked on and not a round trip to the dataserver to perform a lock
- hits a delete button, or save for updating the changes.
- for new record, hit new button, add data for each field and then save

based on the action and the active record the user is working on an appropriate RMI call is made with the selected record then the locking/unlocking is all done at the server side as one atomic transaction with in the del/update/create operations.

All the above activities dosen't need the user to perform lock/unlock ? and the sun UI spec dosen't talk about it either. any comments ?

3. Now about the timeout (as I said), I think (and thats only my opinion) that the time out is a little bit agains/over the specification(at least over my specs). On the other side is hard to find the perfect value for time out because you don't know how long can take a read/write operation.

Well, timeout is not a requirement, but many Database vendors does provide this as a deadlock recovery situation, because potentially if there is no recover mechanism, then the DB would stall a production environment.
so thought adding few more lines of code wouldn't hurt for Locking 80 marks. I thought it is reasonable and will let sun know i have though about it and handled. any comments ?
[ December 01, 2005: Message edited by: steve mcdonald ]
 
steve mcdonald
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i updated the original thread code formatted with [CODE /CODE] format.

also added my design details and assumptions.
when i read instruction and reviewed my design, i think it is little contradictory on the sun requirements.

* Locks a record so that it can only be updated or deleted by this client. If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.

instructions just mentions the client and not the clientid or some sort.
In my Opinion, Though the DB Interface has exposed public lock and unlock methods those are meant to be used with in the DB Server operations to hold locks, i believe this is not a contract between the client UI and Database Server. I believe the business delegate should not expose lock/unlock as API calls to UI. Prevention of concurrent clients accessing and performing critical actions need to be serialized or controlled entirely by the back-end database server. (that is the responsibility of any database server).

The DB Locks should be very very small and if the user is given a chance to control lock .. do some actions wait for hrs and days .. unlock, then practically the system is very unusable.


Any comments.

Thanks ya all for your input

[ December 01, 2005: Message edited by: steve mcdonald ]
[ December 01, 2005: Message edited by: steve mcdonald ]
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Steve,


To make things simple. A selection from the UI, (is only at the UI as a marker, involves no round trip to the server) and as soon as the user presses book, then it is an atomic operation via RMI -> calling the dataclass and then delete/create/update operations on the record. So i believe it is guaranteed that a unique thread is assigned for each atomic concurrent client request ? right or wrong ?



I think you are wrong, as far as I understand you call from the client side in a synchron (atomic) block the "delete/create/update operations", but also if on your client side the block is atomic that doesn't means that on the other side all the request are done by the same thread. If you remeber the example from the "Max book" the socket example, there each reques was handled in a separed thread. Sometihng similar must be used by the RMI also.

In a simplistic way the situation look like :

Client.doStuff -> RMI -> Data.doStuff

If you see between the Client and Data is the RMI.


All the delete/update are atomic operations perform lock/unlock with in the method call,


If you choose to handle in this way the lock/unlock then you don't need to expose the lock/unlock methods, but you must expose them because the interface.


Well, timeout is not a requirement, but many Database vendors does ........



Is more easy to prevent something before it happents that to try to find it and recover.


Regards,
Mihai
[ December 01, 2005: Message edited by: Mihai Radulescu ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic