• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S Data.java Deadlocks

 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.
 
Titus Barik
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]

 
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic