• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Data Object/LockManager

 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic