How to understand "Lock the database"

Hello everybody,
I'm not quite sure what is meant by

-1 locks the database

.
Does this mean that
you should cease granting new locks but still allow clients to unlock their own previously locked records
or
block unlocking requests as well

Thanks,
A.

Hi Andrew,
That's what I'm doing. Whenever a request to lock the whole datebase comes in, I set a boolean to true and if there are any currently locked records I call wait(), I don't allow any more records to be locked, and allow the currently locked records to be unlocked before granting a whole database lock.
It seems to me that if you just allowed the whole database to be locked, disregarding locked records, confusion on the clients could ensue if not downright chaos.

Hope this helps

Michael Morris

Actually the easiest way to look at it, is to think when will lock(-1) be called. How about just when the database is to be closed by the server. Then you should try to lock each and every record by looping through the record count calling lock() with each record number, this way if that record is locked it will wait till the client unlocks it, then it will continue till it locks everything, then the server calls data.close. End of story.

Mark

Hi Mark,
Sounds like a good idea. I'm still wondering though about the requirement to ignore a request to unlock a record that was not locked by the calling client. Is it necessary to authenticate the client or just assume "proper behavior" from the clients that we've created?

Michael Morris

hi,Michael:
The key point is that every client has to have a specific remote data connection object, which is identified by its id or sth else. in my design, to achieve that, u have to use a connection factory object, which is registered in the rmi registry. When the client require a remote data connection object, the client will looking for the connection factory object and get a data connection object which belongs to this client. that means every client has a data connection of its own, not sharing with each other! and then, in the data connection object, u do not need to worry about if it has "lock" the record before. if everything o.k, it should "lock" the record and of course, u'd better check it first. i don't know if i make things clear. hope it help!
And another question ask for Mark:
u said that when client A calls lock(-1), if records are still locked, then A have to wait until notifyAll() is called.
But if another client B is waiting for the locked records as well and after the notifyAll(), JVM decide which one can enter into running state. if unfortunately B is choosed and A has still to wait....in this situation, may be forever. Am i thinking right?
Xiaoma

client A

There is no client A in my example, there is Server A. Because only the server will call lock(-1), no client would or should call lock(-1) in this assignment.

in this situation, may be forever. Am i thinking right?

Yes, but eventually the server will get all the locks, and it should wait that long for the clients to finish. Also the time between lock and unlock from any client really should be millisecond, if that. lock - read - modify - unlock
Mark

Hi Xiaoma,
I guess my point in all of this is that I can think of a thousand different ways to authenticate the owner of the lock when unlock is called, but there are drawbacks in all of them. It sounds like what you are doing creates a dependency between the Data object and the object calling lock and unlock. It would be simple to add a method to the Data class like startTransaction(int record) which could keep internal state data on which client wants to lock which record. But then you should probably subclass Data instead of modify it.

If anyone can help out with this I would appreciate it.
Michael Morris

hi,Mark:
i just finished my lock(-1) and it work well. my logic is as following:
first, loop through a HashSet to check which record is locked. if it is not, then lock it. this is done because i do not want records to be locked by other server objects after i call the lock(-1).
second, if record are currently locked, then wait. Here, i use recursive method to do it. and this idea is coming from your post!
last, call close() to close the database and return a DatabaseException (i need to do that ?).
Xiaoma

return a DatabaseException

Nope don't need to do that unless there is an actual error that occurs.
Mark

Xiaoma,
Is this the only reason you work with a connection object, namely to assure that no client can unlock another client's lock ?
If so, it looks like overkill to me, returning a long on and passing this same ID to seems so much easier to me

Of course, changing the signatures is needed, but is this so a bad idea ?
I'm still not convinced of the need for a connection object

Thanks,
Nico

Nico - Six of one, a half dozen of the other.
They both can work, and in some cases you might find your way easier to write.
However, in terms of OOP and decoupling things. It is a prettier design and also a more maintainable, extensible, and scalable method of this requirement.
Should the Data class be responsible to know anything about a client. No. But you could say, hey, all it knows is a number, and if that number matches what is in my locking "Array" then I let it unlock. I would say even though it is just a number, it is still added implementation to the lock method code that doesn't "define" lock. This is also why using a LockManager class also helps.
When I create methods I think of 3 things
1. The code in this method should do only one thing, and that thing is completely defined by the class it is in, and the name of the method.
2. If this code is taking me more than 10-15 lines of code, then I am not following rule #1.
3. Even though it all seems to me to do one thing, what aspects of it could I still abstract out to decouple objects.
In the case of adding the clientID to the lock method breaks all three of my rules.
Mark

hi,Nico:
My remote connection class is not only for the one-to-one relationship between client and server. In the connection class, it contains all the method to be called in the remote mode. Actually, it is an adapter of the Data class. so u can use adapter design pattern here.
To distinguish the connection class instance, there is a int id in the connection class.
I don't know i am make u clear or even..
Thanks
Xiaoma

Hi there,
Thanks guys for pointing that out, you ( almost ) convinced me to follow your technique

Thanks !

Thanks to all of you !
I see that when record number -1 is called for a lock (most of) you go into a loop to result in a lock on all the recordnumbers. Is this really necessary ?
Couldn't we just cease granting new locks and wait() until the "lockedCollection" is empty ?
Something like this :

I appriciate your comments.
A.

Hi Andrew,
That's exactly what I'm doing. This method is totally deterministic and avoids recursion. I'm not saying it's a better method than locking all the records so long, as Mark pointed out, only one thread ever requests a database lock. For me it seems more intuitive just to prevent futher locks and wait for the Hash to empty.
Michael Morris