Data Object/LockManager

[Kirk Maze]

Is everyone creating a virtual database for the LockManager to hit against when it record locks? I see no discussion about such a wrapper, but I can't for the life of me figure out how to implement record level locking without it. Is there a Collection that I'm unaware of that looks like a database table with an internal row object I can lock on, or should I write my own Table object, Record object, and Field object, and give them appropriate generic behavior? I can't help but believe the latter is outside the scope of the project or 1) there'd be more discussion of it on this forum and 2) they'd let this virtual object we're building drive the interface with the client, rather than forcing us to use the interface designed by the intern.
But the only locking mechanism I know of requires an object to lock on, and the only object I have is the whole database. HELP!

[Robin Underwood]

Please search this forum for info on locking. There have been many threads and several different ways to do it.
I think the typical method is to have LockManager hold a HashMap of record numbers and client identifiers (often the connection object itself is used to identify the client).
My particular implementation uses a HashMap of record numbers and Lock objects.
Hope this makes sense.

[Kirk Maze]

Thanks Robin, but I have done nothing but do all these searches. I guess my problem is that all of the concrete implementaions of a LockManager I've seen, synchronize on an object of some sort. For example, if I've instanciated something of type Record, and I want to to make a method call on that instance, I know how to write a ReadWriteManager that insures all the business rules for reading and writing to that record instance. I don't however, have any idea how to implement a locking mechanism, when there is no instance of something equivilant to Record.
This leads me to the better, but way out of scope, solution of writing a virtual database, and locking on it's elements.
So once again, what am I missing? How do I lock access to a record in db.db, when there's never been any unique instances of it created?

[Robin Underwood]

In most implementations, LockManager knows nothing about Data, and Data knows nothing about LockManager. Another class (such as a remote data connection object) would control both Data and LockManager. It would use LockManager to find out whether it has permission to modify the record number in Data.
I wonder if this is what you mean by a virual database.

[John Smith]

This leads me to the better, but way out of scope, solution of writing a virtual database, and locking on it's elements.

You are headed in the wrong direction. My entire implementation of record locking (including database lock) is 24 lines of code. All you have to do is this:
-- when you are in lock() (or the corresponding method of your LockManager), wait() until the record lock becomes available (that is, your lock collection does not contain the record number)
-- once you are in unlock, release the record lock (remove it from the lock collection) and notify() waiting clients.
Once you have it, you can build the client identification on top of this, or as part of this:
-- if your client identification is on top, you would simply ignore the call to unlock() from the the remote client if that client didn't lock the record.
-- if your client identification is part of your LockManager, you would make your lock collection a Map, wich will map the locked record to the client who locked it.
There is an enormous amount of information about locking/unlocking in this forum, and all the answers (including some code) are practically given.
Eugene Kononov.

[Kirk Maze]

Eugene says:

when you are in lock() (or the corresponding method of your LockManager), wait() until the record lock becomes available (that is, your lock collection does not contain the record number)

I was afraid that's how you were all implementing a lock using only a clientId (or Connection object) and an int. And I can surely write it - it's far simpler than what I was proposing. But I don't see how it's at all threadsafe.
Let say a we request a lock. At the time of the request, there are 10 records and we are requesting a lock on a record numbered 7. Since there are currently other locks qued up for record number 7, our request waits. While we are waiting, a request that was already in the que acquires the lock it was waiting for, which happened to be for record number 2. This request, however, was for a delete. It deletes record number 2. In due course, we acquire our lock for record number 7 and we execute our request, for ease, lets say it's a simple read. We are now going to be given a read on record 7, but the record we really wanted is now at record 6 - we have just read what we previously thought was record 8.
Contrast this with a virtual database (you would probably know it as a cache Robin, sorry for the confusing syntax, it's just the title for a piece I wrote for my current real world project).
When we asked for a lock on record 7, what we were really asking for is a lock on the object that currently is carrying record number 7. In the same situation, by the time we get to it, it's record number is now 6, BUT IT'S STILL THE SAME OBJECT. So when our request exits the que, it returns the correct object to our client.
I'm sure with all of the people who have utilized LockManager with a lock(int recNum, Connection con) design, it must work and there must be something I am missing, but for the life of me I can't figure out what it is.
I would sure appreciate your guidance.
Kirk

[Kirk Maze]

Eugene wrote:

There is an enormous amount of information about locking/unlocking in this forum, and all the answers (including some code) are practically given.

Robin wrote:

Please search this forum for info on locking. There have been many threads and several different ways to do it.

You guys are both assuming that I'm asking for help without having bothered to read the archives. Given the fact that that occurs with some frequency around here, I don't blame you. However, that is not the case in this instance.
I have read every single lock thread (and connection thread, and factory thread!), that the search engine turns up, and have bookmarked those with significant content. I have used Rose to diagram a complete server side solutionand client side solution. I have written an unsophisticated client to bang away at the server when it is done. I have designed a package solution which deploys nicely when the project migrates to an n-tiered, thin client architecture, an occurance I believe inevitable providing FlyByNight survives economically and which I've not seen anticipated here (except in a post I authored a few weeks ago.
Finally, if you still have doubt that you're talking to a guy who is taking this assignment seriously, please note the timestamp on this and the preceeding post! And yes, I do have to go to work this morning.
Thanks for your help!
Kirk

[Eduard Jodas]

Let say a we request a lock. At the time of the request, there are 10 records and we are requesting a lock on a record numbered 7. Since there are currently other locks qued up for record number 7, our request waits. While we are waiting, a request that was already in the que acquires the lock it was waiting for, which happened to be for record number 2. This request, however, was for a delete. It deletes record number 2. In due course, we acquire our lock for record number 7 and we execute our request, for ease, lets say it's a simple read. We are now going to be given a read on record 7, but the record we really wanted is now at record 6 - we have just read what we previously thought was record 8

Record number 7 is always record number 7, no matter if record number 2 has been deleted. Records don't change their position. This is a valid db:
Rec 1: FLIGHT001
Rec 2: FLIGHT004
Rec 3: ** DELETED ** OR ** EMPTY **
Rec 4: FLIGHT002
Rec 5: ** DELETED ** OR ** EMPTY **
When 'Rec 3' was deleted, 'FLIGHT002' remained in 'Rec 4'. It wasn't repositioned automatically to 'Rec 3'. That's why locking on record number instead of on object works.
Once you've obtained a lock on a record you must ensure:
1. it has not been deleted by another client
2. the flight number is the one you expected. If not, the record might have been deleted and another flight might have been put in the same position
3. the flight data (e.g. the available seats) fits your needs

[Robin Underwood]

Once you've obtained a lock on a record you must ensure:
1. it has not been deleted by another client
2. the flight number is the one you expected. If not, the record might have been deleted and another flight might have been put in the same position
3. the flight data (e.g. the available seats) fits your needs

I didn't worry about #2 because I don't think this can happen. What does everyone else think?

[Kirk Maze]

Eduard said:

Record number 7 is always record number 7, no matter if record number 2 has been deleted. Records don't change their position. This is a valid db:

You are absolutely right - I knew it was just a small issue I was banging my head against!
However, you now raise another issue entirely - we can certainly check for null, but we can't check to insure the flight is still the same one we expected to be at that position - (at least not server side) we don't have anything to compare it to except an int recNumber.
Thanks!

[John Smith]

Kirk wrote:

.. but we can't check to insure the flight is still the same one we expected to be at that position - (at least not server side)..

Yes, we can. After you lock the record, re-read it from the database to verify the flight and to make sure that there is still enough seats available (as someone might have reserved the seats between the time when you initiated booking and the time when you actually locked the record).
Eugene.
[ June 25, 2002: Message edited by: Eugene Kononov ]