A client may have more than one lock, but only if he can successfully acquire the second, third, and so on locks. If he can't, then he aborts acquisition.
"The UrlyBird catches the certificate. And he's gonna FlyByNight"<br /> <br />SCJP 1.2/5.0, SCJD, SCBCD, SCWCD, SCEA
Originally posted by Wei-ju Wu:
Sounds like the Banker's Algorithm. There is actually another possibility - the described problems arise because you have more than one Data instance. If you only have one, it is less likely that you will have nested critical sections.
This is what I'm struggling with. If I have multiple instances of Data, I can use 'this' as the lock cookie. If I don't, then what can I use? My lock and unlock interfaces do not accept a second parameter, only the record number.
Is there another lock value that I could use instead that would allow me to have only one data instance? I don't see one. Using the current Thread is not consistent over RMI, and other techniques don't work unless lock and unlock can take in the client ID.
The above example that I gave was borked, but the point is still there: should I only allow a client to lock only one record at a time? The reasoning behind this is to prevent clients from holding onto multiple records, preventing other people from doing updates.
[ May 17, 2005: Message edited by: Titus Barik ]
[ May 17, 2005: Message edited by: Titus Barik ]
Originally posted by Lara McCarver:
What is the problem with only letting the client lock one record at a time? I was originally worried about how to implement partial booking and
Originally posted by Mike Grandmaison:
For example, my client talks through RMI and says Book(). The server on the rmi side then translates that into lock, read, update, unlock. So the client at least in terms of rmi doesn't have to know anything about locking.
That's one possible implementation that I've been tossing around. The other is that the client should have access to the Data via RMI, because Data is a general-purpose database access tool, so that other people can write other clients for other databases without touching the server. After all, Data can load any database format of MAGIC_COOKIE 513 or 515 or whatever, not just the B&S database.
The reasoning for the second approach also comes from the fact that lock and unlock are exposed in Data, and have to ensure that only the client that locked can unlocked. There's no reason to have these methods do client validation at all if you are wrapping Data in your own BookingService class.
But can I programmatically restrict any client from locking more than one record with Data.java, i.e, by throwing a ClientAlreadyLockedRecordException or something to that effect? Is this acceptable?