SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD) - OCEJWCD
John Oconnor wrote:conection type SOCKET selected, principal reazon, avoid work with threads;
John Oconnor wrote:i have only lock the records when the user select a record in GUI , and select a action (reserv or delete), this lock is maintain until the user cancel or confirm the operation(delete or reserv)
Michael Enudi wrote:set an expiration for the cookie say for instance 60 * 1000 that is 1 min
Marcel van den Boer wrote:
John Oconnor wrote:conection type SOCKET selected, principal reazon, avoid work with threads;
Okay, last time I worked with Sockets (which admittedly is some time ago) I had to create a new Thread for every new connecting client. Do you really handle all requests on a single Server Socket? Doesn't RMI give you threading for free?
John Oconnor wrote:i have only lock the records when the user select a record in GUI , and select a action (reserv or delete), this lock is maintain until the user cancel or confirm the operation(delete or reserv)
What if the user does not cancel or confirm the operation? Will the lock hold forever? Other clients trying to lock that record, won't they then also wait forever too? If you only have a single Thread on your server, won't that client block new calls from every other client too, crippling your entire system?
SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD) - OCEJWCD
Marcel van den Boer wrote:
What if the user does not cancel or confirm the operation? Will the lock hold forever? Other clients trying to lock that record, won't they then also wait forever too? If you only have a single Thread on your server, won't that client block new calls from every other client too, crippling your entire system?
SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD) - OCEJWCD
Marcel van den Boer wrote:
Michael Enudi wrote:set an expiration for the cookie say for instance 60 * 1000 that is 1 min
I don't think that would be the best solution. Do you think employees can enter the information in one minute? Maybe. Do you think clients like to wait a full minute (for each other client locking on that record) before getting the message "Sorry, the requested record does not exist any more!". Definitely not.
I think lock(), <verify_on_update>, <operation>, unlock() should be called immediately after each other, in the same method. This way, no lock is held longer than a fraction of a second. The only risk of keeping stale cookies would be when clients crash at the precise time they mutate a record (which is an exceptional case you could decide not to handle in your server).
Marcel van den Boer wrote:
John Oconnor wrote:conection type SOCKET selected, principal reazon, avoid work with threads;
Do you really handle all requests on a single Server Socket? Doesn't RMI give you threading for free?
John Oconnor wrote:-lock system, i have only lock the records when the user select a record in GUI , and select a action (reserv or delete), this lock is maintain until the user cancel or confirm the operation(delete or reserv)
Michael Enudi wrote:I may not have explained it very well but the basic point is to always call unlock() after every operation. But incase of a client crashing in the middle of lock() - unlock(), the record should not stay long forever. So using a time constant to check how long a record has been locked who help indentify expiration.
Marcel van den Boer wrote:
2. You seem to call lock() on a record and then allow the GUI to maintain that lock indefinitely if not another button is pressed. I expressed my concerns about this approach by asking you how other clients will respond to this situation. My opinion is that you should keep a lock as short as possible (less than a second), to avoid any wait times at other clients which are interested in the same record. But you may have your reasons to do it differently. If you know that your other clients will behave without problems, then explain how that works in your CHOICES.TXT.
SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD) - OCEJWCD
If you make sure that the time a record is locked, is kept to a strict minimum (that is: start the whole process when user confirms the booking), then a client crash would be very rare in the middle of the operation, so that's unlikely to happen. If you even use a thin client approach, the above scenario is impossible. So you are adding extra complexicity to your program which is not needed at all if you have a good design.
Roel De Nijs wrote:You should always try to keep your lock-time as short as possible, so when user confirms the update you start the whole process (lock/update/unlock) is better than already locking the record when it's selected by the user from the JTable
I validated the customer id to be an 8-digit number as the instructions stated it should be an 8-digit number.
SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD) - OCEJWCD
Michael Enudi wrote:The optimistic locking in JPA that is achieved by using the @Version on a column designed for that purpose informs my decision on using this approach.
The time limit on the lock cookie duration on the other hand was I idea I got from Monkhouse to avoid holding the lock forever incase of a crash/power off in between the client calls.
Roel De Nijs wrote:
Maybe you should reconsider the update process and you should implement something like:
a) lock
b) verify if record is still available
c) update or throw an exception (depending on the result of b) as you don't want to have double bookings)
d) unlock
SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD) - OCEJWCD
John Oconnor wrote:or when delelte a record, the user confirm delete,
a) lock
b) verify if record is still available
c) save in database as delete record(delete logically)(or throw a exception if already delete)
d) unlock
Roel De Nijs wrote:
First of all: delete functionality is not required in your GUI and you won't receive any credit for doing that.
Secondly: when a record does not exist anymore, because it was already deleted, I would expect the lock-method to throw a RecordNotFoundException, not the delete-method itself.
SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD) - OCEJWCD
Roel De Nijs wrote:
Marcel van den Boer wrote:
John Oconnor wrote:conection type SOCKET selected, principal reazon, avoid work with threads;
Do you really handle all requests on a single Server Socket? Doesn't RMI give you threading for free?
Yes, it does! So that's simply a bad motivation (as you already indicated).
SCJP 5 - OCMJD 6 - OCPJME1MAD(SCMAD) - OCEJWCD