wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S Data.java Deadlocks Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S Data.java Deadlocks" Watch "B&S Data.java Deadlocks" New topic
Author

B&S Data.java Deadlocks

Titus Barik
Greenhorn

Joined: May 15, 2005
Posts: 24
Consider the following example:

DBMain A = new Data(PRISTINE_DB_FILE);
DBMain B = new Data(PRISTINE_DB_FILE);

A.lock(0);
B.lock(1);
A.lock(1);
B.lock(0);

A and B are permanently stuck, waiting on each other's locks to clear. There's only a few ways out that I see for this situation:

1.

A client may only have one lock at a time.

2.

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.

Only on the first lock does the client wait to lock it.

Any ideas?
Wei-ju Wu
Ranch Hand

Joined: Feb 16, 2005
Posts: 147

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.


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.


"The UrlyBird catches the certificate. And he's gonna FlyByNight"<br /> <br />SCJP 1.2/5.0, SCJD, SCBCD, SCWCD, SCEA
Titus Barik
Greenhorn

Joined: May 15, 2005
Posts: 24
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 ]
Lara McCarver
Ranch Hand

Joined: Dec 09, 2003
Posts: 118
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 unbooking of records, which would typically require you to change 2 records, but I think the records could be modified sequentially, meaning only 1 needs to be locked at a time.

So for a "book", first you update the existing record to have fewer contractors available and be "owned" by the customer. Then you add a new record with the remainder. For an "unbook", there may be an existing available record for the contractor, as well as the record that the customer owns. First I would delete the record that the customer owns. Then you would update the existing available record to increase the number of workers available. In both cases, it is OK if someone grabs the record in between because the database is always being conservative about how many workers are available for the contractor.
Titus Barik
Greenhorn

Joined: May 15, 2005
Posts: 24
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


There's no problem with it. In fact, that's what I'd like to do. I'm just not sure if that's what we're allowed to do it without losing points.
Mike Grandmaison
Greenhorn

Joined: Apr 14, 2004
Posts: 12
In my design the client per se doesn't have access to locking/unlocking. All locking/unlocking is done on the serverside and is hidden from the client through a facade.

You don't have to strictly adhere to the interface that sun gives you. You can always use the adapter pattern and allow your client to use whatever methods you want.

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.

I also think in terms of security this is better since the client can be executed on a physically seperate machine if the locking were done in the client then someone could potentially reverse engineer the protocal, write their own client and then steal or ignore locks.
Titus Barik
Greenhorn

Joined: May 15, 2005
Posts: 24
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.

In either case, the question remains the same. You've prevented clients from locking multiple records with a social contract (the book method). 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?
[ May 17, 2005: Message edited by: Titus Barik ]
Mike Grandmaison
Greenhorn

Joined: Apr 14, 2004
Posts: 12
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.


There is no requirement for this and although it is an interesting idea you won't get extra points for functionality that is not required.

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.


I agree with you in terms of code structure that since my server is doing the locking the lock cookie pretty much becomes meaningless except in the case of extending the application where the developer is adding new methods to the bookingservice with the lockcookie he must properly implement method according to lock/unlock or the method will fail and the failing will warn him that he is improperly implementing the method.

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?


I think with your design it would be fair to throw a onlyOneLockPerClient exception.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: B&S Data.java Deadlocks
 
Similar Threads
B&S Locking Strategy RFC
Please comment my design
NX Contractors: Data instances and locking
(B&S):Lock cookie importance
Does the lock associate session ID or customer ID?