Is my lock mechanism correct ?

[Mihai Radulescu]

Please comment my mechanism.

I chose to isolate the lock functionality from the data access functionality and for this I have 2 classes(two interfaces with two implemetations) the LockManager and the DataAccess.
Each client gets its own Data instance.from my server but all the cleitns use the same DataAccess and LockManager

The Data acts like a facade.It hides the database and provides a common simplified accs to it. Technicaly it delegates all the request to the DataAccess or LockManager.

The LockManager has 2 synchron methods (lock and release).

In the Data class I synchrinize using the lockManagerInstace (remember I have the same LockManager for all the clients) my the read, update, create, delete and search.

by example my create method does :

....
synchronized (warpLockManager) {
    //uses the data access features to get a specified record.
    final String[] record = warpDataAccess.getRecord(recNo);
 
   if (record == null) {
      //no record was found in the database
      throw buildRecordNotFoundException(recNo);
    }
 
    return record;
}
....

or my update method does :

....
synchronized (warpLockManager) {
    checkIfRecordExist(recNo);
    checkIfRecordIsLock(recNo);
    warpDataAccess.modifyRecord(recNo, data);
}
....

the checkIfRecordIsLock does :

private void checkIfRecordIsLock(int recNo) {
    if (!warpLockManager.isLocked(recNo)) {
        final StringBuffer noLockMsg = new StringBuffer();
        noLockMsg.append("The record : ");
        noLockMsg.append(recNo);
        noLockMsg.append("must be locked before operate.");
        throw new RecordIsNotLockedException(noLockMsg.toString());
        }
}

I think that one of my most important is the lock method :

....
synchronized (warpLockManager) {
    //locks a record, if a client tries to lock a locked recod he must wait
    warpLockManager.lock(recNo, clientId);
    if (!warpDataAccess.recordExist(recNo)) {
         // if the record was deleted unlock the client.
         warpLockManager.release(recNo, clientId);
         throw buildRecordNotFoundException(recNo);
    }
}
....

because the LockManager has 2 synchron methods there is no danger of nested locks.

Comments, critics, sugestions, tips ?

Regards,
Mihai

[ November 29, 2005: Message edited by: Mihai Radulescu ]
[ November 30, 2005: Message edited by: Mihai Radulescu ]

[Pawel Poltorak]

Hi Mihai,

I'm thinking about your lock method. Mine is similar, but I check for existing records before locking. I'm wondering why you lock and then, if record is not existing anymore, unlock? Or maybe I'm missing something?

Best Regards,
Pawel

[Mihai Radulescu]

Hi Pawel

I have also a version for lock method where I check if the record is existig before locking :

....
synchronized (warpLockManager) {
 
    if (!warpDataAccess.recordExist(recNo)) {
         //if the record is deleted
         throw buildRecordNotFoundException(recNo);
    }
 
    //locks a record, if a client tries to lock a locked recod he must wait
    warpLockManager.lock(recNo, clientId);
 
    if (!warpDataAccess.recordExist(recNo)) {
         // if the record was deleted unlock the client.
         warpLockManager.release(recNo, clientId);
         throw buildRecordNotFoundException(recNo);
    }
}
....

In this way If a record is deleted an exception (RecordNotFoundException) occurs. Otherwise if the record is aviable the client locks the record - if other clients try to lock the record they must wait until the record is unlocked - if the record is unlocked I ckeck once more (maybe the record was deleted).
The last check runs always, that why I remove the first check(in the actual lock method), this makes the method a little bit less performant - but it makes also the method more simple.

I hope this answers your questions.



Regards,

Mihai
[ November 29, 2005: Message edited by: Mihai Radulescu ]

[Pawel Poltorak]

I see... I'm checking if record exists just before adding locked entry into map. This way, if record was deleted in the meantime, locking attempt doesn't occur and unlocking is not needed.

Best Regards,
Pawel

[steve mcdonald]

guys, one thing i don't understand is, where and how the clientid being generated and how it is unique for each client for multiple request/response activities

nevermind, i have gone throuh a lot of threads relating to this one.
i think i might think about the using one of the concurrent atomic classes to gen a unique client id, upon registration with the server and return to the client to keep track of its further concurrent sessions.

but however i would not let the client perform lock/unlock operations asynchronous to transactions. because txn's have to be small and atomic and not controlled by the client.
[ December 01, 2005: Message edited by: steve mcdonald ]

[Mihai Radulescu]

Hi Steve,

I don't know what you mean with

lock/unlock operations asynchronous to transactions

because the lock/unlock are atomic.

and not controlled by the client.

The client (user) makes the transaction (it use the databse) otherwise the server(databse) alone with no user/no transations it makes no sense.
[ December 01, 2005: Message edited by: Mihai Radulescu ]

[steve mcdonald]

well what i meant was that,

because lock and unlock are public and they are exposed in the interface.

1. are you exposing those methods to be used the n/w client ?
if yes, are you calling them non atomically ? from the UI like lock and then do other operations and then unlock ?

User selects a record for lock -> 1 operation with request/response comes back tothe client then
perform delete/update on the selected record (another request/response)
user unlocks.

i presume you are not doing this. are you ?

well, another question for you, how are you handling the clientid issue ?
are you generating a unique id for every client connection ?

[Mihai Radulescu]

Hi, Steve

User selects a record for lock -> 1 operation with request/response comes back tothe client then
perform delete/update on the selected record (another request/response)
user unlocks.

You just make some serious presumtion here. In this way only clients using a specific logic(your logic) can operate your database. You an not be shore that in the future only your client will operate the database. Let's say that in the future someone want to change only the front end, the new front end is contrains to use the same logic.
In other words if you want that only one client type can operate your server you must have serious reasons(and documetn them).

how are you handling the clientid issue

I obtain the connection object from the server, more clients, only one server and here it goes.

you can take a look on my design on :

[url=https://coderanch.com/t/187655/java-developer-SCJD/certification/Please-comment-design]https://coderanch.com/t/187655/java-developer-SCJD/certification/Please-comment-design


Regards,
Mihai.

[Sanjay Mistry]

--- Sorry Mihai to hijack your thread. I have questions with same heading.

Hi Guys,

I am almost finished with the assignment (B&S 2.3.1). I just want to know if my locking is adequate.

For update & delete - client checks if locked, if so then message user else lock, update/delete, unlock. (##)

For create - checks duplicate, if so the message else create.

For update - checks duplicate, if so the message else update.

Each request to server is synchronized, create a new instance of Data. (this will address the "multiple concurrent clients of your server")

What does this mean? "Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available".

What is the resource?

Does it mean, that if record is lock then return and give message, OR that while a client is busy accessing the file then the other client must wait with no CPU cycles?

Have I resolved this problem by "class-lock" a method or have I missed the boat totally?

The other baddy in my architecture is that client is requesting lock/unlock and the interface required to be implemented does not cater for me to identify who locked the record. However, I can still change my Data class to cater for this. But will it be necessary as it makes not difference to locking itself where I locked or someone else locked 'cause the client runs this in sequence as mention above (##).

Any ideas?

Regards
Sanjay

[steve mcdonald]

i got you, So you return DataClient instance (Serialized) to the Client and that reference is your client id. right. Cool !

Well another question ?
- So your server must be tracking this reference for lock / unlock checking.
- Are you sending the DataClient object in ever request to the Data Server code for client identification ?

How do you handle stale DataClient references ? of crashed/suspended/aborted clients in the Server code ?

[ December 02, 2005: Message edited by: steve mcdonald ]
[ December 02, 2005: Message edited by: steve mcdonald ]

[Mihai Radulescu]

Hi, Guys

Thanks for the interest.

Let's start with Sanjay.

On the fist view your lock metodology looks acceptable. One question here, you check also if the record exist ?

Each request to server is synchronized, create a new instance of Data.

I don't get it if every client has his own Data instance it haveno sense to synchronize it.

What is the resource?

I don't know how your database is looking bur in most of the cass it contains records - one record is one resource. You must be able to lock only one resource (record) and let the rest aviable, so

I resolved this problem by "class-lock"...

is not the optimal solution.

The other baddy in my architecture is that client is requesting lock/unlock and the interface required to be implemented does not cater for me to identify who locked the record. as mention above (##).

If you need to identify who locked the record just use an adapter. I try to picure it for you below :

client1 -> adapter \
lock
client2 -> adapter /

Hi Steve,

So your server must be tracking this reference for lock / unlock checking

No the server responsability is to serve(even if it sound funny), my sever just provides the lock mechanisms.

Are you sending the DataClient object in ever request to the Data Server code for client identification.

No, for every of my clients I have a connection object (I think DataCleint in your case)

How do you handle stale DataClient references ? of crashed/suspended/aborted clients in the Server code ?

Her' I can asnwer with only one word : Unreferenced (java.rmi.server.Unreferenced).

Regards,
Mihai.
[ December 03, 2005: Message edited by: Mihai Radulescu ]