What if the same client execute lockRecord twice

[Jack Nam]

Hi Everybody,

I am doing the URLyBird Version 1.2.1 currently. I would like you to advise me on the lockRecord() method.

It is stated that "If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked". The question is what is supposed to happen if a client execute the method twice? With the code I wrote, the thread waits forever in the loop.

These are my method. Anybody would like to give me a suggestion?

	public long lockRecord(long recNo) throws IOException,
			RecordNotFoundException {


		recordLock.writeLock().lock();

		long cookie = 0;
		try {
			while (true) {
				if (!doesRoomExist(recNo))
					throw new RecordNotFoundException(recNo + " is not found.");
				
				if (lockedRecords.get(recNo) != null) {
					recordLockCondition.await();
				} else {
					cookie = generateNewCookie();
					lockedRecords.put(recNo, cookie);
					break;
				}
			}
		} catch (InterruptedException ie) {
			// handle exception
		} finally {
			recordLock.writeLock().unlock();
		}
		
		return cookie;

	}

[Pushkar Choudhary]

Just Nothing wrote:

Please change your display name to use your real first and last names. Obviously fictitious names are not allowed under JavaRanch's Naming Policy.

[Jack Nam]

Pushkar Choudhary wrote:

Just Nothing wrote:

Please change your display name to use your real first and last names. Obviously fictitious names are not allowed under JavaRanch's Naming Policy.

Ok, I just changed it. It is weird though.

[Roel De Nijs]

Hi Jack,

I throw an IllegalSateException. But there are other alternatives. Useful information can be found in this thread.

Kind regards,
Roel

[Roberto Perillo]

Roel De Nijs wrote:I throw an IllegalSateException.

Me too!

[Jack Nam]

Thanks for the advices. I think I get it.

But how you do you keep tracking what client locking what recNo? Since the interface doesn't include clientId, I guess it must be done at the upper layer.

Am I right?

[Roel De Nijs]

Hi Jack,

If you are able to follow the same approach depends on which interface you have. If you have an interface with the infamous lockCookie you'll not able to track down which client locked which record. If you have one without the lockCookie (like me and Roberto) you can add a client-dentification method to your own interface (which extends the given - required to implement - interface). This approach is described in this thread (and in a bunch of other threads too ).

Kind regards,
Roel

[Jack Nam]

Roel De Nijs wrote:Hi Jack,

If you are able to follow the same approach depends on which interface you have. If you have an interface with the infamous lockCookie you'll not able to track down which client locked which record. If you have one without the lockCookie (like me and Roberto) you can add a client-dentification method to your own interface (which extends the given - required to implement - interface). This approach is described in this thread (and in a bunch of other threads too ).

Kind regards,
Roel

I got the one with the cookie. So, if I can't track the client, how would I know if the same client lock the same recNo twice in a row? this cause the thread waits forever.

I am thinking to create an upper layer to manage the security exception related to the cookie. Anybody have any experience or opinion about this would be appreciated.

[Roberto Perillo]

Howdy, Jack!

So, if I can't track the client, how would I know if the same client lock the same recNo twice in a row?

Oh, you certainly can track the client. After some thinking, I realized that maybe, what they expect from us is to realize that, if your lock() method does not return a value, then you should implement a thin client. This way, the transaction will be controlled on the server side. If it returns a value, then you can either implement a thick or a thin client.

This is my answer to my good buddy Andrew's question: Should lock methods be callable by the client? Well, if the lock() method return a value, then you may control the transaction on the client side, and expose the lock() method in a remote interface to the client. On one hand, it is easy due to the value returned; on the other hand, it's like using the Exposed Domain Model pattern. Particularly, I don't really like the idea of controlling the transaction on the client side. If your lock() method does not return a value, then it is easy to control the transaction on the server side using Thread.currentThread().getId(), and then you'll not expose the lock() method to the client.

In the case of the thin client, your business method is implemented on the server. Consider the following (just notice the modeling so you can understand):

public interface Services {
    public void bookRoom(long recordNumber, String customer) throws ServicesException, RemoteException;
}

public class DefaultServices implements Services {

    private DBMain db;

    public DefaultServices(DBMain db) {
        this.db = db;
    }

    public void bookRoom(long recordNumber, String customer) throws ServicesException {
        db.lock(recordNumber);
        String [] record = db.read(recordNumber);
        record[6] = customer;
        db.update(recordNumber, record);
        db.unlock(recordNumber);
    }
}

public class Data implements DBMain {
    /* This Map keeps the locked records, where the key is the record number, and the value is the client id */
    private Map<Long, Long> lockedRecords = new HashMap<Long, Long>();

    public void lock(recordNumber) {
        long clientId = Thread.currentThread.getId();
        // While the record to be locked is in the lockedRecords Map, the current Thread has to wait...
        // the notification for the waiting Threads to wake must be done in the unlock() method,
        // and a good tip is to notify all Threads (notifyAll()).
        // After this notification, you must verify if the record to be blocked still exists, because the delete() method
        // also requires the record to be locked before deletion. In the update() and delete() methods, it must be
        // verified if the client requesting the operation is the same that locked the record, and only this client
        // can unlock it.
        lockedRecords.put(recordNumber, clientId);
    }
}

public interface RemoteServices extends Services, Remote {
    // You can add here the things you find necessary
}

public class RMIRemoteServices extends DefaultServices implements RemoteServices {
    // Implement something you eventually added to your server...
}

If your lock() method returns a value, you can then return it to the client side and implement the locking logic there. I myself came up with a different approach (you can find more info about it here), and I agree that it introduced a little more complexity than necessary. My lock() method does not return any value, but I came up with a way to implement a thick client, and controlling the transaction on the client side.

[Jack Nam]

Roberto Perillo wrote:Howdy, Jack!

So, if I can't track the client, how would I know if the same client lock the same recNo twice in a row?

Oh, you certainly can track the client. After some thinking, I realized that maybe, what they expect from us is to realize that, if your lock() method does not return a value, then you should implement a thin client. This way, the transaction will be controlled on the server side. If it returns a value, then you can either implement a thick or a thin client.

This is my answer to my good buddy Andrew's question: Should lock methods be callable by the client? Well, if the lock() method return a value, then you may control the transaction on the client side, and expose the lock() method in a remote interface to the client. On one hand, it is easy due to the value returned; on the other hand, it's like using the Exposed Domain Model pattern. Particularly, I don't really like the idea of controlling the transaction on the client side. If your lock() method does not return a value, then it is easy to control the transaction on the server side using Thread.currentThread().getId(), and then you'll not expose the lock() method to the client.

In the case of the thin client, your business method is implemented on the server. Consider the following (just notice the modeling so you can understand):

public interface Services {
    public void bookRoom(long recordNumber, String customer) throws ServicesException, RemoteException;
}

public class DefaultServices implements Services {

    private DBMain db;

    public DefaultServices(DBMain db) {
        this.db = db;
    }

    public void bookRoom(long recordNumber, String customer) throws ServicesException {
        db.lock(recordNumber);
        String [] record = db.read(recordNumber);
        record[6] = customer;
        db.update(recordNumber, record);
        db.unlock(recordNumber);
    }
}

public class Data implements DBMain {
    /* This Map keeps the locked records, where the key is the record number, and the value is the client id */
    private Map<Long, Long> lockedRecords = new HashMap<Long, Long>();

    public void lock(recordNumber) {
        long clientId = Thread.currentThread.getId();
        // While the record to be locked is in the lockedRecords Map, the current Thread has to wait...
        // the notification for the waiting Threads to wake must be done in the unlock() method,
        // and a good tip is to notify all Threads (notifyAll()).
        // After this notification, you must verify if the record to be blocked still exists, because the delete() method
        // also requires the record to be locked before deletion. In the update() and delete() methods, it must be
        // verified if the client requesting the operation is the same that locked the record, and only this client
        // can unlock it.
        lockedRecords.put(recordNumber, clientId);
    }
}

public interface RemoteServices extends Services, Remote {
    // You can add here the things you find necessary
}

public class RMIRemoteServices extends DefaultServices implements RemoteServices {
    // Implement something you eventually added to your server...
}

If your lock() method returns a value, you can then return it to the client side and implement the locking logic there. I myself came up with a different approach (you can find more info about it here), and I agree that it introduced a little more complexity than necessary. My lock() method does not return any value, but I came up with a way to implement a thick client, and controlling the transaction on the client side.

Roberto, thanks for the input.

I think thin client approach offers simplicity, but on the minus it doesn't allow client to do the pessimistic transaction (might be not necessary).

[Roel De Nijs]

Jack,

Please, don't quote a complete post of someone else. It has no added value and just wastes some disk space. Use quotes wisely!

on topic: if you have a lockCookie you can't know if clientA has already locked another record (in your Data class). You can add of course this logic on a higher level or you can just do something like this:

However, this can easily be remedied by ensuring the JavaDoc and the choices.txt clearly define that it is the responsibility of the client to ensure lock/update/unlock is one atomic operation, ie. that the unlock is called on a locked record prior to locking the same record again:

More info found in this post.

Kind regards,
Roel