Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Two Levels Locking

 
Tiago Fernandez
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,

I'd like to discuss a little bit about my locking approach. Ok, as I said on the subject,

I've implemented on 2 levels:

1. Of course, the first level concerns about DB interface. Both lock/unlock methods are called by my business class, which use them before booking/unbooking/reading records. So, on Data class I'm locking records.

2. Inside Data (which implements DB), I use another class called FileManager to play with an RandomAccessFile instance, doing the "dirty job". So, my FileManager also has lock/unlock methods, and all the requests to the database are handled there. The point is, one thread by time does something on the databasc. Clarifying: I'm locking the whole database file, no matter what is being done there.

When booking, I always check if the record was booked before (raising an exception in this case).

Does anybody see problems locking also the whole database file? What about lock/unlock being called by a business class only, and not the GUI, is this ok?

Thanks for reading.
 
George Stoianov
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am currently preparing for the exam and have not dealt with locking a lot, so feel free to completely ignore my comments.

I think that locking the whole database would be OK if you had that in the assignment and it was explicitly stated. I have worked with a few databases, I mean RDBMS, and they all implement row-level locking at least the best. This has a great impact on performance and user experience when dealing with multiple users accessing the same db.

My second comment is regarding locking you have to different tiers implementing locking, I think you should abstract that so that you can localize the changes to one or more specific classes.

Good luck.
George
 
Tiago Fernandez
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm locking the whole database file because my FileManager class is a synchronized singleton, and has an instance of RandomAccessFile. So, let's say someone is reading the file, and at the same time, someone else updates another record. I guess the RandomAccessFile's file pointer would get lost and the file would get broken.

The only solution I see for this is to have more than one RandomAccessFile instance for handling different requests.

Which two do you think is best? If you have another idea, please share :-)

Tks
 
George Stoianov
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you want to implement row level locking than you would have to implement some sort of an object that contains a row of the file and lock that as soon as someone attempt to perform an update. You file manager than would be responsible for monitoring the file and keeping track of the rows, which one is locked and which one isn't. I think you would have to have some sort of time out for locks as well, but as I said I do not have a lot of experience with file io in java and don't know the api to give you a specific example or suggestion. The way I see the file management is like this, mainly based on my db background. 1) you have a file object that represents the whole file it is responisble for doing general file stuff, open, close, size, loop through records etc. 2) that file is composed of row and columns as objects these have specific row and column type methods. Depending on you assignment this maybe greate over blown but it will give you flexibility and is, I think aiming for good OO. Now having the row object you can have code synchronized on operation on a row only, you can also abstract the locking functionality so that you can apply the time out there.

I hope this is a better explanation and gives you ideas.
regards,
george
 
Animesh Saxena
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make ur Data class as Singleton.....And u can use kinda LockManager class which keeps a Hasttable for Locked Records. So if anyone locks the record just enter it into this Hashtable...

When somebody uses ur Data class to update a different row...create a new instance of RandomAccess file to do it.....

maybe u can place the insertRecord and RetrieveRecord functions in ur Data file as private functions...so other functions can use these to get access to ur low level Database File. Other functions listed in the interface won't have to bother about File Handling....they will ofcourse be public....

Hope this helps....
 
Tiago Fernandez
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Animesh and George for replying.
I'll implement both solutions and check which fits better to the application.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic