Complete locking schema or how to avoid 44/80 on locking.

[Anton Golovin]

Good day!

I finally figured out the complete locking system. Locking at the Data class level does not do all the trick. There needs to be supporting locking at the business logic level for certain methods.

If your locking at the Data method is fine, consider this:

in your bookRoom() method in your business logic, do you check that a room is not booked? This functionality properly belongs here. After you check it is not booked and that it is bookable (within 48 hours, say), you book it. But what has happened between your reading the record from your cache/datafile, and your writing the record to your cache/datafile? The record could have been manipulated in a variety of ways, and there is no guarantee that the record you are writing is the same.

So if you do not implement some sort of supporting locking in your business logic, you did not implement locking for a 100% score.

Basically, it is solved by synchronizing on your Data class in your business logic, where appropriate.

Please comment.

P.S. In my particular case, my Data class is thread-safe by itself. However, when I need to synchronize on the Data class in my business logic, sometimes the code acquires locks twice. That, to my knowledge, is no problem. However, when, thus "twice-locked", the code runs my Data-level locking code, the wait() method in it has to release and reacquire lock on Data class. I would appreciate comments as to any nuances in this situation.
[ August 31, 2004: Message edited by: Anton Golovin ]

[peter wooster]

Originally posted by Anton Golovin:
Good day!

I finally figured out the complete locking system. Locking at the Data class level does not do all the trick. There needs to be supporting locking at the business logic level for certain methods.

If your locking at the Data method is fine, consider this:

in your bookRoom() method in your business logic, do you check that a room is not booked? This functionality properly belongs here. After you check it is not booked and that it is bookable (within 48 hours, say), you book it. But what has happened between your reading the record from your cache/datafile, and your writing the record to your cache/datafile? The record could have been manipulated in a variety of ways, and there is no guarantee that the record you are writing is the same.

So if you do not implement some sort of supporting locking in your business logic, you did not implement locking for a 100% score.

Basically, it is solved by synchronizing on your Data class in your business logic, where appropriate.

Please comment.

The ability to lock a record at the business level is exactly what the record locking mechanism does. The "book" sequence is {lock, read, compare, update, unlock}. This is needed regardless of whether you are doing rich or thin client. Synchronizing in the business class in the rich client does no good, in the thin client model it will solve you problem, but it will probably cause problems with responsiveness, and open up lots of opportunities for deadlock.

One of Doug Lea's basic principles is "never lock when invoking methods on other objects". In that quote he means use of synchronization when he says "lock". In our projects we can follow this principle if we synchronize on the RandomAccessFile when calling methods on it. If you synchronize on the business object and then call file access methods you are breaking this rule.

[Anton Golovin]

Here's the code I was referring to:

 
 public boolean bookRoom(int recNo, String[] newRoom) throws
            RoomManagerException {
 
        String[] existingRecord = null; // will store existing record recNo
 
        synchronized(data) {
 
            try { // reads in the existing record
                existingRecord = data.read(recNo);
            } catch (RecordNotFoundException rnfEx) {
                throw new RoomManagerException(rnfEx.getMessage());
            }
 
            // checks if existing record is bookable
            if (!bookingRules.isBookable(existingRecord)) {
                throw new RoomManagerException("Record " + recNo +
                                               " can not be booked at this time.");
            }
 
            if (bookingRules.isBooked(existingRecord)) {
                throw new RoomManagerException("Record " + recNo +
                                               " is already booked.");
            }
 
            long cookie = 0L;
            try {
                cookie = data.lock(recNo);
            } catch (RecordNotFoundException rnfEx) {
                return false;
            }
            try {
                data.update(recNo, newRoom, cookie);
            } catch (SecurityException secEx) {
                return false;
            } catch (RecordNotFoundException rnfEx) {
                return false;
            }
            try {
                data.unlock(recNo, cookie);
            } catch (SecurityException secEx) {
                return false;
            } catch (RecordNotFoundException rnfEx) {
                return false;
            }
 
            return true;
        }
 
    }
 

How would you handle the possibility that between the read and lock/update/unlock another thread modifies the record in question? I am thinking of locking the Data class for the entirety of those operations. But if there is a better way, please elaborate.

An alternative would be to move the read method within the lock/unlock, but then I also may have to call the read method for things that do not require this type of checking, and then I would need to be sure read fetches current data. So I need it to check if a record is locked and wait until it becomes unlocked. It is a dilemma, and any advice would be greatly appreciated.
[ August 31, 2004: Message edited by: Anton Golovin ]

[mike acre]

Originally posted by Anton Golovin:
Here's the code I was referring to:

synchronized(data) {

You have synched on data for the whole book method.
That means no one else can do anything to any other record during the whole of your very time consuming book method.
I'm sure you do not need to nail it down this much.

[Paul Bourdeaux]

An alternative would be to move the read method within the lock/unlock

I think this is a better solution than locking the entire Data class. That way you can have concurrent reads on different records in the database.

but then I also may have to call the read method for things that do not require this type of checking

Can you give me an example of when you would need to do this?

[Philippe Maquet]

Hi all,

Here are a few quick comments on what I've read here.

Mike:
You have synched on data for the whole book method.
That means no one else can do anything to any other record during the whole of your very time consuming book method.
I'm sure you do not need to nail it down this much.

I totally agree with you, Mike.

Peter:
The ability to lock a record at the business level is exactly what the record locking mechanism does. The "book" sequence is {lock, read, compare, update, unlock}.

I agree too. And the way the DBAcess interface is designed shows that SUN's intent was to let the business tier manage locking independently of any other data access.

Anton:
An alternative would be to move the read method within the lock/unlock, but then I also may have to call the read method for things that do not require this type of checking, and then I would need to be sure read fetches current data.

If you follow the sequence Peter described above, you're sure that reads fetch accurate data which cannot be changed until you unlock.

Regards,

Phil.
[ September 01, 2004: Message edited by: Philippe Maquet ]