Locking dumb question

I'm not a native English speaker. I must confess I'm a bit confused with the locking needs on the assignment. Here's my spec:

Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

Think with me ...
1. Client A and Client B request for book the same record
2. Client A lock the register
3. Client B waiting for his thread to be free
4. Client A update with his information
5. Client B tries to book the same registes with diferent owner ???

If so Clients A and B will think they booked the register if Client B must handle this situation and advise the user that the record isn't avaiable anymore. Should I verify if the record is avaiable for update before writing the owner id ? I read here a thread from a guy who sent a message to the client telling that the register is locked and he failed in the test.

What are you doing ?

Thanks,
Tony

Hi
Sticking to the requirements of the assignment is very important
When that guy solved the problem by telling the user that the record is not available he did violate the following requirement in the assignment which is:

Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

If so,according to what he did,then there is no need to make a thread waiting till the lock is released.I have noticed from the threads in this forum that most people fail the exam because not sticking to a requirment.

And this leads to another question:Can a client book more than one record at the same time???

Another question comes in mind:
Client A locks the record
Client B attemps to lock the same record
Client A deletes the record
Client B now do now do not find the record
What will happen at the GUI side of the application???

Good luck to anyone applying for the SCJD

I think it's strange to follow the reqs without taking care of this situation. Anybody has any comments on both cases ?

Any help would be fine !

Thanks
Tony

Originally posted by Tony Bouer:
I think it's strange to follow the reqs without taking care of this situation. Anybody has any comments on both cases ?

Any help would be fine !

Hi ranchers,
what do you think about this piece of code

I think it's pass yours examples.

Regards
Ales'

I can't see how this code is going to solve the issue I raised. If you are on the waiting state and receive the "go ahead" (the recNo is not locked anymore) so you should verify again if the record still valid or not. It could be deleted or updated with an owner making it non availble for update or delete.

Regards,
Tony

Originally posted by Khaled Mahmoud:
And this leads to another question:Can a client book more than one record at the same time???

If you have a multithreaded user interface, why not?

Originally posted by Khaled Mahmoud:

Another question comes in mind:
Client A locks the record
Client B attemps to lock the same record
Client A deletes the record
Client B now do now do not find the record
What will happen at the GUI side of the application???

If you implement it properly, client B will get notified that the record was deleted (or altered) on disk and either get an error or be asked to confirm that he wants to write it anyway.

Should I verify if the record is avaiable for update before writing the owner id ? I read here a thread from a guy who sent a message to the client telling that the register is locked and he failed in the test.

What are you doing ?

the way I did this was

A thread trying to obtain the lock on a record waits until the lock can be obtained. If after obtaining the lock, the thread realizes that another thread has updated the record, an ConcurrentModificationException is thrown, this exception is handled on the client, which updates the record, and tells that the record has been updated by someone else.

Originally posted by Tony Bouer:
I can't see how this code is going to solve the issue I raised. If you are on the waiting state and receive the "go ahead" (the recNo is not locked anymore) so you should verify again if the record still valid or not. It could be deleted or updated with an owner making it non availble for update or delete.

Regards,
Tony

Hi Tony
In example code there is "checkRecForBook(rec);" in try block.
this method throw an exception if:
- we can't booked this room because it just booked by someone else.

So now we must only handle this exception and show user the message.

This is my proposition, but i haven't yet SCJD certificate

Regards.
Ales'
[ August 16, 2006: Message edited by: Ales Moukhine ]

Hi!

Regarding the Concorrent Exception, if I'm using the socket approach (not rmi), how can I send this exception to a client?

Thanks for your thoughts ... Luiz I'm not sure about what to do in case of sockets.

Regards,
Tony

Hi, Tony.

I'm thinking in always send to a socket client a ResponseVO, and this object will have a field named "errorMessage". So, the socket client read this field and, if necessary, throws a Exception to be catched in the client GUI to show a message.

In the "local" approach I also send such Exception to the client GUI.

Is it a good approach? What you think?

I will post this question as a new topic. Thanks!