Just be aware that if you are using RMI and exposing your Data class' methods via the remote interface that the thread ID could change between calls. It may not matter for your usage, however it can mean that two separate clients could get the same cookie (thread ID).
Originally posted by s yucel:
i had the same problem, and I am thinking to use the thread id as it is a unique value.
if the client decides to rewrite the implementation of the server and just reuse your Data class then the problem could suddenly start manifesting itself.
No - I was only showing the "booking" business logic which (in my example) has a call to lock and a call to read in it. But clients calling read() or find() would not need to lock records.
Andrew, I did understand,that in your solution client is loking every record whil reading it (for showing in table) and releasing it while closing/reloading table/ etc? Am right?
Ahh - the question about optimistic or pesimistic locking. Searching for either of those terms in this forum will bring up a few posts on the subject. Suffice it to say that both ways are valid, although the optimistic locking solution tends to get greater supporters here. Mainly because of the potential for a client to click the "Reserve" button (thereby locking the record) then receiving a phone call / being called away ... Another client tries to reserve the same record and effectively gets blocked (it may appear that the client application has frozen) until the first client gets back to whatever they were doing.
In my version I've decided to have functionality of displaying table without locking. When user presses "Reserve" button client is
-displaying locked row in separate dialog
-waiting for user input
-after confirmation updating an unlocking
The only problem what i see is that record can be in "lock" state for quite a long time.
Nice workaround to the problem I just mentioned (which is why I mentioned it above and not here ). However you are going to build a much larger solution than is really needed - you might want to consider how much less effort is going to be required with optimistic locking.
I want to preserve it by adding listener pattern for broadcasting information about locking and other changes. Locked records wouldn't be able to select.But it breakes the simplicity rule a bit. What do you think?
Thanks for your little novel