A client can lock many records at a moment?

[Light Wan]

Hi all,
I use the 2 tiers structure implement my lock mechanism. To avoid deadlock occur or some other problems, one network client should only lock one record at a time. My implementation is that in LockManager, an object could lock two different record. At client side, in DataAccessFacade, I synchronized the DataAccess(Server side), it means that at a time, only one thread of this client could access DataAccess. Is it need to implement one client cannot lock more records at a moment? If so, how did you implement?
Regards.
Light

[Andrew Monkhouse]

Hi Light,
I don't believe your solution will stop a client from locking more than one record - it just stops one client attempting to call the lock() method from two separate threads. Your client could still lock one record then, after that was successful, lock another record.
There are many options available to you. Some of them are:

Ignore the issue - just make sure that the client you write can only lock one record

Force the database to reject any lock() requests if the given client attempts to lock a record while it currently owns a lock (you would need to check whether this is even possible with your instructions)

Stop the possibily of deadlocks by forcing locks to be requested by a client in numerical order (again - check if your instructions allow such a restriction)

Stop the possibility of deadlocks by writing a deadlock detection routine (again - check if your instructions allow such a restriction)

Regards, Andrew

[Light Wan]

Hi Andrew,
Yes, you are right. I am not sure the solution will prevent a client to lock more than one record. And as you think, maybe it is not very useful to implement that. So, I decide to ignore this issue. The following is the coding in my lock method:

 
    public void lock(int recNo, Object recordLocker) throws Exception {
        synchronized (lockMap) {
            Integer recordKey = new Integer(recNo);
            if (recNo == DATABASE_KEY.intValue()) {
                lockDatabase(recordLocker);
            }
            else {
                lockRecord(recordKey, recordLocker);
            }
        }
    }
    private void lockDatabase(Object recordLocker) throws Exception {
        synchronized (lockMap) {
            while (!lockMap.isEmpty()) {
                try {
                    lockMap.wait();
                }
                catch (InterruptedException ie) {
                    throwInterruptedException(ie);
                }
            }
            lockMap.put(DATABASE_KEY, recordLocker);
        }
    }
    private void lockRecord(Integer recordKey, Object recordLocker)
        throws Exception
    {
        synchronized (lockMap) {
            while (isLocked(recordKey)) {
                try {
                    lockMap.wait();
                }
                catch (InterruptedException ie) {
                    throwInterruptedException(ie);
                }
            }
            lockMap.put(recordKey, recordLocker);
        }
    }
    private boolean isLocked(Integer recordKey) {
        synchronized (lockMap) {
            return (lockMap.containsKey(DATABASE_KEY)
                    || lockMap.containsKey(recordKey));
        }
    }

I think the above coding will work fine. Do you think so? I expect some of you check these codes. Thanks very much.
Regards,
Light

[Philippe Maquet]

Hi Andrew,

Stop the possibility of deadlocks by writing a deadlock detection routine (again - check if your instructions allow such a restriction)

Restriction ?! Could a system which whould avoid deadlocks (a very bad scenario by definition) through a detection routine bring some restriction on the locking system ?
But I found very interresting the restriction concept regarding the instructions. Now let's take the four possible solutions you mention with that restriction concept in mind :

Ignore the issue - just make sure that the client you write can only lock one record. It's a very acceptable solution IMO, but I would document that a deadlock - at the db level - may occure, while it cannot happen in this application (because users cannot book more than one record at a time).

Force the database to reject any lock() requests if the given client attempts to lock a record while it currently owns a lock : at the db level it is a restriction in comparison with what the instructions ask.

Stop the possibily of deadlocks by forcing locks to be requested by a client in numerical order. It is a restriction. Nowhere instructions talk us about any required order in lock claiming.

Stop the possibility of deadlocks by writing a deadlock detection routine : there is no restriction to the instructions, because the given lock interface may freely be used as exposed (including the grant of multiple locks to the same client), while in the same time deadlocks cannot happen.

Solution 4 if definitely the best one, even if I do believe that it is not mandatory within the scope of this assigment. If I had to rank them, I would say : 4-1-3-2.
Best,
Phil.

[Philippe Maquet]

Hi Light,
It's the first time I read this lock() method signature here :
"public void lock(int recNo, Object recordLocker) throws Exception".
Which instructions did you get (including version number) ?
What's the Object recordLocker parameter that you never use BTW ?
THis said, and reviewing your code, it seems OK to me, except the useless synchronized (lockMap) block in your isLocked method.
Best,
Phil.

[Andrew Monkhouse]

Hi Light,

I expect some of you check these codes.

I choose to believe that this sentence is an example of a bad translation into English. For future reference, in that context, it reads as though you believe that we, as your employees, should be checking your code for you. And that will upset many people. It would be better to ask "Could someone please comment on my code".
Do you have a requirement to lock the entire database? If not, then I would remove the entire method which locks the database.
If you do have a requirement to lock the entire database, then what is the logical outcome if the database is locked? Should a client be able to get a lock on an individual record while the entire database is locked? Do you prevent this from happening?
What is your "recordLocker" object?
I presume that this lock() method is in your LockManager. Is it being called by lock() in your Data class?
Regards, Andrew

[Andrew Monkhouse]

Hi Phil,

Andrew Stop the possibility of deadlocks by writing a deadlock detection routine (again - check if your instructions allow such a restriction)
Phil Restriction ?! Could a system which whould avoid deadlocks (a very bad scenario by definition) through a detection routine bring some restriction on the locking system ?

There is a restriction - you are restricted from deadlocking the system
Hmmm - one of these days I will have to learn English
What I meant was whether the signature of the lock method allows deadlock handling.
There are some people who's signature for the lock() method does not allow them to handle deadlock. For example, my Hotel assignment has the following:

// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. 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.
public long lock(int recNo) throws RecordNotFoundException;

Now according to those instructions, there is nothing I can do if deadlock occurs, except throw a RuntimeException.
In fact, the options 2, 3, and 4 I mentioned earlier could only be handled by throwing a RuntimeException.
I really don't like the idea of throwing RuntimeException, but I also don't like the idea of deadlock. I think throwing RuntimeException is the lesser of two evils, but you would have to be certain it was really well documented, as it is quite possible that this could catch some poor client when some future application is in production.
But this is further than I wanted the initial conversation to go. I was hoping to have Light realise that there might be a problem with what exception to throw, and then think about it before we give away solutions
Regards, Andrew
[ October 16, 2003: Message edited by: Andrew Monkhouse ]

[Philippe Maquet]

Hi Andrew,

If you do have a requirement to lock the entire database, then what is the logical outcome if the database is locked? Should a client be able to get a lock on an individual record while the entire database is locked? Do you prevent this from happening?

Light does it in his isLocked() method. It's OK IMO.

There is a restriction - you are restricted from deadlocking the system
Hmmm - one of these days I will have to learn English

You made me ROFL !

There are some people who's signature for the lock() method does not allow them to handle deadlock (...)

I think none of them.

Now according to those instructions, there is nothing I can do if deadlock occurs, except throw a RuntimeException.

Agreed.

I really don't like the idea of throwing RuntimeException, but I also don't like the idea of deadlock. I think throwing RuntimeException is the lesser of two evils, but you would have to be certain it was really well documented, as it is quite possible that this could catch some poor client when some future application is in production.

That's exactly what I think myself : throwing a RuntimeException (DeadlockException in my implementation) and document it, is still better than let the application hanging because of a deadlock.
Now I'll keep that idea of restriction you brought into the discussion. It's an important issue IMO. Because restricting some instruction is - by definition - not fulfilling it :

In solution 2, throwing a RunTimeException in case a client just claims a second lock means enforcing by a RuntimeException (bad by nature) a business rule of our own that maybe the customer doens't want to be applied.

And solution 3 does exactly the same, except that the additional business rule is different. Throwing a RuntimeException just because locks are not claimed in numerical order means "I stop you working, not because of a deadlock, but because a risk of dealock". It's so harsh !

Best,
Phil.
[ October 16, 2003: Message edited by: Philippe Maquet ]

[Light Wan]

Hi Philippe,

Which instructions did you get (including version number) ?

URLyBird 1.3.1

It's the first time I read this lock() method signature here :
"public void lock(int recNo, Object recordLocker) throws Exception".
What's the Object recordLocker parameter that you never use BTW ?

This lock() method is in my LockManager class. I use a connection factory to returns a new RemoteDataAccess object to every network client. The recordLocker is a RemoteDataAccess object.
The recordLocker parameter is to specify who locked a record. It is used in unlock method to unlock a record.

     public void unlock(int recNo, Object recordLocker) {
        synchronized (lockMap) {
            Integer recordKey = new Integer(recNo);
            Object locker = lockMap.get(recordKey);
            if (locker == null || locker.equals(recordLocker)) {
                lockMap.remove(recordKey);
                lockMap.notifyAll();
            }
        }
    }

    public void unlock(Object recordLocker) {
        synchronized (lockMap) {
            if (lockMap.containsValue(recordLocker)) {
                Collection lockers = lockMap.values();
                while (lockers.contains(recordLocker)) {
                    lockers.remove(recordLocker);
                    lockMap.notifyAll();
                }
            }
        }
    } 

My server implements Unreference interface. If client called close() or client crashed, the method unlock(Object recordLocker) will be called in RemoteDataAccess class. RemoteDataAccess does not remember the records it locked.

THis said, and reviewing your code, it seems OK to me, except the useless synchronized (lockMap) block in your isLocked method.

Yes, you are right. the synchronized (lockMap) block in isLocked method is useless.
Regards,
Light

[Light Wan]

Hi Andrew,
Oh, my god, my poor English. I'm sorry. I apologize to all of you. Thank you, Andrew, thank you figure out my problem.

Do you have a requirement to lock the entire database? If not, then I would remove the entire method which locks the database.
If you do have a requirement to lock the entire database, then what is the logical outcome if the database is locked? Should a client be able to get a lock on an individual record while the entire database is locked? Do you prevent this from happening?

Yes, I need to lock the entire database. In create() method on Data class, my implementation is just appending new record at the end of database file. And in Data class, there is a recordsCount field, which indicates the count of records(live and unlive) in database. So, in the creating process, I need to lock the entire database, append the new record, recordsCound++, and then unlock the whole database. When the entire database is locked, no client can get a lock on a record. The preventing mechanism is implemented in lockRecord() method on my LockManager class.

What is your "recordLocker" object?
I presume that this lock() method is in your LockManager. Is it being called by lock() in your Data class?

Yes, presented codes are in LockManager. The lock() method does not being called in my Data class, but in my RemoteDataAccess clss. Every client has its own RemoteDataAccess object. These RemoteDataAccess objects share a common Data object and a common LockManager object. So, "recordLocker" is a RemoteDataAccess.
Regards,
Light

[Philippe Maquet]

Hi Light,

The lock() method does not being called in my Data class, but in my RemoteDataAccess clss.

Do you have this in your instructions ?

Instructions:
Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:

If yes, how did you implement lock and unlock in Data ?
Notice that that sentence is a "must" one. What about implementating them by delegating their job to your LockManager ?
Best,
Phil.

[Light Wan]

Hi Philippe,

If yes, how did you implement lock and unlock in Data ?
Notice that that sentence is a "must" one. What about implementating them by delegating their job to your LockManager ?

Yes. I must implement the lock and unlock method of DBMain interface. But in order to encapsulate lock mechanism into LockManager class, the lock and unlock method in Data class just overlay the lock and unlock method defined in DBMain interface, but do nothing.
The lock/unlock method being called process is:

CSRDataAccessFacade-->RemoteDataAccess-->LockManager  

I don't think it must be in the following steps. And the following implementation violates the SRP(Single Responsibility Principle):

 CSRDataAccessFacade-->RemoteDataAccess-->Data-->LockManager 

Regards,
Light

[Philippe Maquet]

Hi Light,

The lock/unlock method being called process is:
code:
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->LockManager (1)

I don't think it must be in the following steps. And the following implementation violates the SRP(Single Responsibility Principle):
code:
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data-->LockManager (2)

I understand why you chose (2) (lock/unlock Data signatures annoyed you as they annoyed me) but I think you violate the requirements : by defining lock() and unlock() as empty methods in Data, do you implement them ? Not IMO.
Reading your LockManager class, I conclude that you designed a single-table db system (which is what most of people do, so it's OK).
And with this simplest design, it's possible to implement lock/unlock in Data without altering its lock/unlock methods signatures, as far as you instantiate one Data instance per client :

public void lock(int recNo) {
    lockManager.lock(recNo, this);
}

Now maybe you decided to instantiate only one Data instance because of a few things you wanted to keep unique per file (a cache for instance). But as your design is single-table, those unique things may be static.
Solution (2) becomes then :

CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client 1) \
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client 2)   ---> LockManager
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client n) /

With a multi-table design like mine, things are a little more complex, but it's still possible to keep Data lock/unlock method signatures unchanged though implemented them, as far as you use Data as follows :

CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client 1) \
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client 2)   ---> Table 1 \
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client n) /                \
                                                                                        ---> LockManager   
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client 1) \                /
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client 2)   ---> Table 2 /
CSRemoteDataAccesstaAccessFacade-->RemoteDataAccess-->Data(client n) /

Best,
Phil.
[ October 17, 2003: Message edited by: Philippe Maquet ]

[Ulrich Heeger]

Hi,
after I have read this thread, some questions emerged for me:
1. Following the discussion concerning thin client vs. fat client, I decided that I will have a 2-tier design. But because the business logic would be at client side, then the avoiding of deadlock due to the shut down of the client application (not only client crash but like Light remarked, the client may close the application) becomes very actual.
If for example the client calls the book method, the lock and unlock-method will be called from the client side, and if the client decides to quit the application before unlock() has been called, we may get a deadlock.
I mean that the probability of this situation is much bigger than at 3-tier design, where the business logic will be made at the server side. Is my assumption right? Or do you think I still can omit this potential deadlock for my design without risking to fail the exam?
2. I don't understand why you don't want to allow a client to lock more than one record. Is that because you guys want to use the Data.this-reference as Key-Object in a WeakHashMap? And so create a DeadLockException like Phil's if Data.this allready is in the HashMap?
Thanks a lot & Regards
Ulrich

[Philippe Maquet]

Hi Ulrich,

I mean that the probability of this situation is much bigger than at 3-tier design, where the business logic will be made at the server side. Is my assumption right?

Yes.

Or do you think I still can omit this potential deadlock for my design without risking to fail the exam?

Yes too, because a wide majority of us strongly believe that is possible to pass (even with a perfect score) without handling the deadlock issue.

2. I don't understand why you don't want to allow a client to lock more than one record. Is that because you guys want to use the Data.this-reference as Key-Object in a WeakHashMap? And so create a DeadLockException like Phil's if Data.this allready is in the HashMap?

Mmh... it's not what I did. People who don't allow clients to lock more than one record at a time partly solve the deadlock issue by restricting the way locks are granted. I wrote "partly" because they still write some additional code to handle deadlocks due to crashed clients. But they could do it even if Data.this is not the Map key. What they avoid (but at the cost of a big db-side restriction) is deadlocks due to crossed lock claims. What I did myself is to avoid dealocks due to any of both possible causes, without bringing any restriction to the requirements :

if a deadlock occurs because of a crashed client (he got some lock(s) but crashed before unlocking it/them), the deadlock is immediatetly broken (I mean repaired) without any exception to be thrown ;

if a deadlock occurs because of crossed claims, the "guilty" client (the one who is initiating the deadlock situation) gets a DeadlockException thrown from his lock() call. Getting that exception, he knows that 1) the lock he just claimed was not granted and 2) he lost a previous granted lock wihtout any way to know which one he lost. But as my lock calls are reentrant, he still may claim all the locks he needs and go on with its job.

Hope it's clearer.
Regards,
Phil.

[Ulrich Heeger]

Hi Phil,
thanks for your answer.
You wrote:

if a deadlock occurs because of crossed claims, the "guilty" client (the one who is initiating the deadlock situation) gets a DeadlockException thrown from his lock() call.

I don't understand. How can there be a deadlock due to crossed lock claims?

Getting that exception, he knows that 1) the lock he just claimed was not granted and 2) he lost a previous granted lock wihtout any way to know which one he lost. But as my lock calls are reentrant, he still may claim all the locks he needs and go on with its job.

Ok, let me resume it: Client A has acquired the lock of Record 1. Before unlocking Record 1, Client A also tries to lock Record 2. Client A gets a DeadlockException and within the catch-block for Deadl.ex. I could make a call to get the lock of Record 2 again, is that the way you go?
But why do you force Client A to loose also the previous granted lock for Record 1? And how do you ensure that the action concerning Record 1 will go on? Lets assume that the call book(recNo 1) may have been made before book(recNo 2). Further the client tries to lock Record 2 just before the update(recNo1) is made. Update(recNo1) noticed, it hasn't anymore the lock of Record1. And then? Do you have perhaps within the book-method a catch-block perhaps for SecurityException, which will call lock(recNo1) once more?
Sorry, I hope my thoughts and questions aren't too confusing
Salutations du p'tit suisse
Ulrich

[Philippe Maquet]

Salut p'tit Suisse,

Phil: if a deadlock occurs because of crossed claims, the "guilty" client (the one who is initiating the deadlock situation) gets a DeadlockException thrown from his lock() call.

Ulrich: I don't understand. How can there be a deadlock due to crossed lock claims?

1. Client A locks recNo 100
2. Client B locks recNo 200
3. Client A claims a lock on recNo 200 and wait()
4. Client B claims a lock on recNo 100 and should wait()
At point 4., LockManager tells himself (I noticed that sometimes my LockManager singleton feels so lonely that it talks to itself ) : "if I accept client B's second lock claim, I'll get a deadlock".
So he throws a DeadlockException to B and unlocks his blocking lock (on record 200). As it unlocks it in exactly the same way client B would have done by himself,client A is notified that it can be granted its lock on record 200, and goes on with its normal job.
This is the simplest case. In fact, you could have 25 clients, each of them holding multiple locks without any issue, till let's say client 6 claims a 4th lock as in this situation :
Client 4 owns a lock on recNos 50 and 150 and is waiting for a lock on recNo 200
Client 17 owns a lock on recNos 100, 200 and 300, and claims a lock on recNo 350
Client 6 owns locks on recNos 250, 350 and 500, and claims a lock on recNo 150
If LockManager does nothing, C6 will wait on C4 (recNo 150) which waits on C17 (recNo 200) which waits on C6 (recNo 350), leading all three of them in deadlock.
As you noticed, deadlocks may be indirect (thanks again to Andrew to have pointed it out in july ), so its detection must be recursive.
Facing such a situation, LockManager with unlock C6's lock on recNo 350, notify C17 accordingly, and then throw a DeadlockException to C6.

But why do you force Client A to loose also the previous granted lock for Record 1?

The answer to that question should now be obvious.

And how do you ensure that the action concerning Record 1 will go on? Lets assume that the call book(recNo 1) may have been made before book(recNo 2). Further the client tries to lock Record 2 just before the update(recNo1) is made. Update(recNo1) noticed, it hasn't anymore the lock of Record1. And then? Do you have perhaps within the book-method a catch-block perhaps for SecurityException, which will call lock(recNo1) once more?

Typically, you'll claim multiple locks because you want to perform multiple updates atomically. Even if client-side the user may or may not book multiple rooms at once (it's a server-side property in my implementation), I wrote my server-side business book() method in a generic way : it books a collection of records. In pseudo-code, it should look like :

    void book(long[] recNos) {
        long[] cookies =  new long[recNos.length];
        try {
            while (true) {
                try {
                    for (int i = 0; i < recNos.length; i++) {
                        cookies[i] = data.lockRecord(recNos[i]);
                    }
                    break; // we got all locks we need
                }
                catch (RecordNotFoundException e) {
                    // throw some business-level application exception
                }
                catch (DeadLockException e) {
                    /* the only usefull information here is that we need
                       to restart locking all the records we need */
                }
            }
            // read and check the records here
            // update the records here
        }
        finally {
            for (int i = 0; i < recNos.length; i++) {
                /* unlock doesn't care about trying to unlock a record
                    which wouldn't be have locked before */ 
                data.unlock(recNos[i], cookies[i]);
            }
        }
    }

Best,
Phil.

[Ulrich Heeger]

Bonjour p'tit belge
Thanks for your answers.
Now, I understand.
Can I just ask, how you implement your LockManager so it can check the potential deadlock?
Thanks in advance,
Ulrich

[Philippe Maquet]

Hi Ulrich,

Now, I understand.

Thanks, it means I achieved my aim.

Can I just ask, how you implement your LockManager so it can check the potential deadlock?

Of course you may ask, but unfortunately I think I cannot reply more than what I wrote above :
My private recursive checkDeadlock method is only 29 lines long, including 5 closing curly braces lines and 9 comment lines : only 15 "real-code" lines long. But if I post them, nobody here will understand them, taken out of their context. Including javadoc comments and blank lines, my LockManager.java file is 741 lines long. And you'll understand that if I post them all here while Andrew is sleeping, Andrew will get an attack when he wakes up.
No, sorry, but I like Andrew too much.
Best,
Phil.

[Svetlana Koshkina]

I thought that here are some fine points:

1. Luckily, I suppose, most of the assignments don't impose necessity of locking multiple records at a time, i. e. decision you are making on one particular record does not require you to look into another record: situation when you have to lock two records simulteniously and keep them locked for duration of the transaction. In our assignment once you are done with the record you can unlock it right away. Signature of the method also takes one arg not an array, so you lock-unlock one by one, which allow you for very efficient implementation.
2. Also, you might be interested to know that although the assignment require you to implement lock-unlock methods on remote client side, nobody actually compells you to USE them. In my ass. I implemented all methods they asked me, but my client lived happily without using them: all locking-unlocking was done on server-side on BEHALF of the client. This allows for easier recovery from deadlocks if they occured. (I've got full score for my implementation.): so it tested. You only need to document all your decisions.
So, maybe lock-unlock is not very hard after all.

[Philippe Maquet]

Hi Svetlana,

Luckily, I suppose, most of the assignments don't impose necessity of locking multiple records at a time

I think none of them. As I wrote above, I do believe that deadlock detection is not required by the assignment.
Among the 4 possible solutions enumerated by Andrew, I ranked solution 1 (ignore the issue) in second position.
It's anyway better IMO to fully ignore the issue and document it than write a partial solution in that area.

Signature of the method also takes one arg not an array, so you lock-unlock one by one, which allow you for very efficient implementation.

In my assignment, there is no specific method signature for booking. At the db level, nothing would prevent you to lock a few records, update them all before unlocking them. But of course you may avoid it as the application writer.

2. Also, you might be interested to know that although the assignment require you to implement lock-unlock methods on remote client side,

Then I suppose you get on old assignment because none of the new ones have such an explicit requirement.

In my ass. I implemented all methods they asked me, but my client lived happily without using them: all locking-unlocking was done on server-side on BEHALF of the client. This allows for easier recovery from deadlocks if they occured. (I've got full score for my implementation.)

Thank you for that useful piece of information. It's so good news for people here who decided to handle locks server-side despite some contrary advices.

So, maybe lock-unlock is not very hard after all.

Lock-unlock may be as simple as a few lines of code. If I had to rewrite that stuff now, that's the simple way I would choose. No doubt.
A common mistake with this assignment is to add our own requirements on top of the basic ones stated in the instructions. Mark shouldn't disagree with me here.
Of course, as the instructions are unprecise on purpose, with "issues deliberately left unspecified" (...) "upon which you are being graded", we may have some excuses to over-engineer a few things. Moreover, each issue you think of quickly becomes a technical challenge it's compelling to try to solve. And as doing so helps you to learn more (if you need it as I did), you go on on the tough track.
Now, actually, when you read "database system" in the instructions, think "single flat file", not "database" as I did.
Best,
Phil.
[ October 17, 2003: Message edited by: Philippe Maquet ]

[Ulrich Heeger]

Hi Phil,
I will try to get a concept of the LockManager. Perhaps I will annoy you once more if I can't go on
Thank you very much
Ulrich

[Light Wan]

Hi Phil,
I am sorry for my so late response. If I call lock/unlock of LockManager directly in RemoteDataAccess, that is not implemte the lock/unlock of Data.
So, I thinked a lot in the past two days. Now, I want to implement a simple solution. My instruction does not need me to remember who locked a record. Just need me to implement that a record should be locked by a connection at a moment. If another client want to lock the same record, the client should wait for the record unlocked. And there is no requirement needing me to think about the multi-tables scenario.
Best,
Light

[Philippe Maquet]

Hi Light,

If I call lock/unlock of LockManager directly in RemoteDataAccess, that is not implemte the lock/unlock of Data.

It seems that I convinced you then.

So, I thinked a lot in the past two days. Now, I want to implement a simple solution. My instruction does not need me to remember who locked a record. Just need me to implement that a record should be locked by a connection at a moment. If another client want to lock the same record, the client should wait for the record unlocked. And there is no requirement needing me to think about the multi-tables scenario.

I think you're making the right decision : keeping it simple and within a single table scenario. And if you keep it simple enough (a static map of locked records), you even don't need a separate LockManager IMO.
Best,
Phil.