3 client types for locking

[ulvi ugur]

Hi All,
I use Simon Roberts' Java 2 Cert Guide. In locking section they describe 3 client types.
1- Active client : Highlighting a row locks the record.
2- On-demand client : Locking is integral to all add/del/modify operations.
3- Lazy client : Requests are queued; notification occurs on a subsequent thread.
I read the explanations for each type but couldn't exactly understand the 2nd and 3rd types. Does anybody know what these represent ?
Thx all.

[Vlad Rabkin]

Hi Ulvi,
1. That when you lock the record each time you select it (I beleive it is totally inacceptable).
2. On-demant: that is when you lock the record before updating it.
3. I had a big discussion with my colleges about the issue. We disagreed in our opinions what it exactly means. So, would better let somebody else comment it, than to provide with the false information.
Best,
Vlad

[ulvi ugur]

Hi Vlad,

2. On-demant: that is when you lock the record before updating it.

What does locking mean in that sense ? Not allowing others to update/delete or search this item ?

3. I had a big discussion with my colleges about the issue. We disagreed in our opinions what it exactly means. So, would better let somebody else comment it, than to provide with the false information.

I think I had a quick look about that shooooort thread. The lazy client is described in the book as "closest strategy to ao an RDBMS, making it computationally expensive to assess which records are in use and which are free. Notification in such environments is usually required to be as quick as possible, seperate threading or not. The usual solution more memory, faster CPU, faster disks, seperate threading....". It is English, but I don't understand a flipping thing about the bold part. Can you say it in layman terms ?
Thx.

[Vlad Rabkin]

Hi Ulvi,
1.

What does locking mean in that sense ? Not allowing others to update/delete or search this item ?

update/delete for sure. Search is questionable. It depends on, which serialization level of transactions you want to have.
My implementation of the assignement allows to read a locked record.
2. Sorry, I will let somebody else to answer it.
I have read the capital in the book many times. I don't like it. The capital gives some ideas, without really explaining them. As I said, I have my own understand of "lazy client", which is most likely wrong.
I would suggest you to forget the capital from the book.
You have clear task:
You must implement locking which would lock a record, making other threads trying to lock the same record to wait. How you implement it is your matter of design and implementation, which has nothing to do with informatiion which you commented from the book.

Best,
Vlad
[ October 28, 2003: Message edited by: Vlad Rabkin ]

[Andrew Monkhouse]

Hi Ulvi,
My interpretation for those three items would be:

Active client : Highlighting a row locks the record.
As Vlad said: this would be where you lock the record at the time it is selected.
The advantage of this is that can you know that the booking will succeed - you do not have to worry about entering lots of information only to find out that the record was booked by someone else in the meantime (assuming you do the relevant checks for record availability at the time of locking the record).
The big disadvantage is that since this record could be locked for a long time (e.g. the person doing the booking gets interrupted for an hour) then any other clients who try to lock this record will be blocked until the booking is committed or rolled back.

On-demand client : Locking is integral to all add/del/modify operations.
This is what most people here do. The user selects the record to modify and enters all the relevant details (e.g. the client identification number), and then clicks the "OK" or "Book" button. The GUI application then calls a method (either client side or server side) that does the "lock, check record availability, update record, unlock".
The advantage is that there is little blocking of other clients (although it can still happen).
The disadvantage is that you do not find out whether the record is still available to you until after you have entered all the booking information. This is not to bad with the SCJD assignments, but it could be annoying (to say the least) if you spent half an hour entering relevant fields and then found out that the record has been booked in the meantime.

Lazy client : Requests are queued; notification occurs on a subsequent thread.
With both the previous scenarios, booking a record happens in real time. And if you have a slow connection to the database, or the database is very busy, or the record you want to modify is locked, you could get blocked for quite a while before you can do anything else.
It would be possible for the server to provide a queueing mechanism. When you try to book the record on the client side, you just send the request to the server, where it is put on a queue. Your client can then continue to book other records. Sometime in the future the server will take your request off the queue and (hopefully) book your record for you, then send notification back to the client GUI.
This is better suited to the Fly By Night Services assignment, where the booking consisted of decrementing number of seats available on a flight - there would be a reasonable chance of a queued request working.
However this is quite a complicated scenario for the SCJD assignment, as you would have to have the client GUI listening for messages from the server, you might want to have some way of notifying clients that records are queued for modification, you would have to think about what to do if the client crashed (so it cannot get notification about whether it's update worked or not), you have to decide what information to return to the client GUI so that they can determine which record that they tried to book is the one they are getting a response to, and so on.

Note that since this is my interpretation of such a limited description, I could be totally wrong

The lazy client is described in the book as "closest strategy to ao an RDBMS, making it computationally expensive to assess which records are in use and which are free. Notification in such environments is usually required to be as quick as possible, seperate threading or not. The usual solution more memory, faster CPU, faster disks, seperate threading....". It is English, but I don't understand a flipping thing about the bold part. Can you say it in layman terms ?

As I mentioned in my description of point 3 above, you might want to track which records are being queued so that a user does not attempt to book the same record twice. But this now means that any client that wants to check availability has to check it in two places - the real database and the list in the queue. This is becoming "computationally expensive": it requires more work just to find out if the record is available or not.
This would become worse if you had more information in the booking request - say each record can have multiple bookings (e.g. FBNS) but each customer can only do one booking. In which case you are not only checking the real database to see if the record is available, and the queue to see if there are outstanding bookings, but also checkin who owns the outstanding bookings: this is becoming more and more "expensive" (have you heard the expression "time is money"? ) to check whether the record is available or not.
However the user still wants to get told (notified) that the booking succeeded or failed as soon as possible after they complete the booking. It is no good getting told an hour after you did the booking that it failed - the customer has already hung up the phone. Unfortunately because of the extra checking, queueing and notification that we are doing on the server, it is now running slower. So we have to upgrade the server to meet customer expectations
I hope some of that made sense.
Regards, Andrew

[Vlad Rabkin]

Hi Andrew,
Tx for joining the discussion.
on-demand:

This is not to bad with the SCJD assignments, but it could be annoying (to say the least) if you spent half an hour entering relevant fields and then found out that the record has been booked in the meantime.

The disadvantage you mentioned is nothing (to my opinion) to advantages of it.
- high level concurrency
- simplicity of implementation
Of course, it depends on the project. If there is a very high possibility that the record changes, you are right. However, if the database is huge and the possibility that a record changes is low - on-depand client(with optimistic locking: if the a record is locked, an exception is thrown) is best design.
That is the point I disgree with the book that queueing is better.
I had a project a year ago. We had MANY millions of records (telephone numbers of the people). The probability that a record changes concurrently is almost zero. So, we used on-demand client with optimistic locking almost overall (we had DB2).
Of course, for FBN, queing is better...
Queueing

Note that since this is my interpretation of such a limited description, I could be totally wrong

That is also my understanding, but my colleges argued the point.
Whatever, I agree totally with you that this design is not candidate #1
for usage in the assignement.
Best,
Vlad
[ October 28, 2003: Message edited by: Vlad Rabkin ]
[ October 28, 2003: Message edited by: Vlad Rabkin ]
[ October 28, 2003: Message edited by: Vlad Rabkin ]
[ October 28, 2003: Message edited by: Vlad Rabkin ]
[ October 28, 2003: Message edited by: Vlad Rabkin ]

[ulvi ugur]

Hi Guys,
Thanks for your replies. Here are my comments.
*) Vlad wrote :

quote:
----------------------------------------------------------------------------
What does locking mean in that sense ? Not allowing others to update/delete or search this item ?
----------------------------------------------------------------------------
update/delete for sure. Search is questionable. It depends on, which serialization level of transactions you want to have.
My implementation of the assignement allows to read a locked record.

My question was more about searching, about dirty reads.I am doing Contractor assignment; I can't "read" anything about this issue. Have you heard of any explicit specs for dirty reads in Contractor ?
*)According to the description Andrew made, here is what I think
- Active client : unnecessarily protective and can be annoying for other users, but excludes the risk of being rejected after entering data.
- On-demand client : gets an explicit input from the user to reserve, thus more intuitive, blocking other users during the transaction is for this assigment is acceptable, has the risk of being rejected after entering data (I need to come back to that).
- Lazy client : oh my God ! Vlad, if you ask me this is a more unacceptable solution for this problem. Imagine situation, "Mr.Bush, I know I told you I reserved a contractor for your leaking loo, but the system just responded that Mr.XXX is not available. I'm afraid you need to live with that sh.. for a while" issed. And I agree, complicated too.
Coming back to the on-demand client (I guess I will go with the flock about this), do you think we can get rid of the rejection risk via locking the record on Reserve action of the user, then getting parameters from the GUI and continue updating the DB ?
You can find what I the activity diagram of the Reserve Use Case under. It could be great if you could tell me what you think about it ?
Best Regards,
Ulvi

[Andrew Monkhouse]

Hi Ulvi,
I am not sure what your initial decision diamond is doing for you. I assume you are calling an isLocked() method on the server. But since you seem to be looping back to that decision, it is not really doing anything for you - you might as well replace it with a call to lock() the record.
Which brings me to the next point - you should lock the record before you check whether the record is deleted or already reserved. Otherwise there is a window of opportunity for another client to reserve the record before you complete the locking.
You may not need the separate decision diamond for checking if the record is deleted or not - the lock() method and isLocked() methods will probably do that check internally.
Regards, Andrew

[ulvi ugur]

Hi Andrew,
Thanks for your reply and sorry for not being around to come back to you .

I am not sure what your initial decision diamond is doing for you. I assume you are calling an isLocked() method on the server. But since you seem to be looping back to that decision, it is not really doing anything for you - you might as well replace it with a call to lock() the record.

My idea about the first diamond was not actually a decision diamond but more a "synchronization" diamond. i.e. wait until the record is free to be locked; which I myself have a problem with regarding the specs "consuming no CPU cycles when the record is locked". I am not sure about this scenario :
1) The user selects a row and clicks on the Book button.
2) The server checks if the record is locked.
3) If it is not continue with the activity diagram; if it is the user is informed that the record is currently locked, and then what ??
Possible alternatives :
a) try again later.
b) release the GUI thread, in another thread wait until the record is released and inform the user when it is available. I have doubts about this too; if this takes a long time and if the user can continue with search/select/anyaction, then it would be a bit weird when a dialog box says his request for XXX has completed; and he goes "which request ??". Am I being hairsplitting or is this a reasonable doubt ??

Which brings me to the next point - you should lock the record before you check whether the record is deleted or already reserved. Otherwise there is a window of opportunity for another client to reserve the record before you complete the locking.

You are absolutely right, I updated my document accordingly.

You may not need the separate decision diamond for checking if the record is deleted or not - the lock() method and isLocked() methods will probably do that check internally.

I just prefer to see all necessary operations for the same use case, surely it should be the job of lock() and isLocked() methods to do the check about deleted records.
Best,
Ulvi

[Andrew Monkhouse]

Hi Ulvi,
I just noticed the "throw RecordNotFound" case for when the record is already booked - that exception IMHO does not match the actual situation - you should be able to throw something more meaningful.

If it is not continue with the activity diagram; if it is the user is informed that the record is currently locked, and then what ??

Personally I would wait a few seconds, then check if the record is still locked. Do that a few times, and if it still locked, present a dialog to the end user telling them that the record is locked and find out if they want to continue or not.
Regards, Andrew

[ulvi ugur]

Hi Andrew,

I just noticed the "throw RecordNotFound" case for when the record is already booked - that exception IMHO does not match the actual situation - you should be able to throw something more meaningful.

You are right about that, however the interface defines the lock method as public void lock(int recNo) throws RecordNotFoundException;
Do you think I should amend it to throw another RecordAlreadyLockedException in that case ?

Personally I would wait a few seconds, then check if the record is still locked. Do that a few times, and if it still locked, present a dialog to the end user telling them that the record is locked and find out if they want to continue or not.

I just wanted to check if there was any obvious points which I missed, got my answer to that.
Best,
Ulvi