• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RAF pooling and physical locking

 
Arun Subramanian
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greetings all-
I am thinking of using a RAF pool for the database I/O operations. I am modelling the RAF pool on the more common JDBC connection pool. In this design, since each networked client will get its own RAF instance besides its own Data instance, I am unsure whether there needs to be any physical locking for the Data CRUD methods. Will logical locking be the solution for all my Data access methods as well as my Business methods?

Any inputs would be much appreciated.

Thanks,
Arun.
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've just implemented a RAF Pool. I originally had a RAF for each Data class. After reading some comments about using too many file pointers I decided to implement the pool. I've implemented a read/write lock on the file level.

My only problem now is I'm unsure where I should close the RAF's. Anyone any suggestions?

Cheers,
Matt.
 
Arun Subramanian
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Matt-
I've just implemented a RAF Pool.

Glad to see you doing the RAF pool as well...

Right now, I have the RAF pool code (methods) in my RMIFactory class and the closeDescriptors() method that closes the RAFs inside the finalize() of the RMIFactory. Later on, I might also have this (and probably any other cleanup code) inside a Thread class that would be passed as an argument to the Runtime.getRuntime().addShutdownHook(Thread hook) method.

I've implemented a read/write lock on the file level.

Can you share your physical and logical locking strategies with some code (pseudocode?). I have run against a wall wrt addressing physical locking as now, in our design, each client can operate with it's own RAF and it's own Data instance.

Thanks,
Arun.
 
Arun Subramanian
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And here's a good explanation of the addShutDownHook() usage by Andrew...
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Arun Subramanian:
Greetings all-
I am thinking of using a RAF pool for the database I/O operations. I am modelling the RAF pool on the more common JDBC connection pool. In this design, since each networked client will get its own RAF instance besides its own Data instance, I am unsure whether there needs to be any physical locking for the Data CRUD methods. Will logical locking be the solution for all my Data access methods as well as my Business methods?

Any inputs would be much appreciated.

Thanks,
Arun.


Are you certain that 2 instances of RandomAccessFile have seperate copies of the file pointer. I considered using multiple RAF's and couldn't confirm this. If they have seperate pointers then that strategy will work, if not there is a chance that a competing client will move the pointer. It's probably not hard to do a test of this, but the result could be system dependent, so you might want to try it on several systems, at least Solaris and WinXP.

I think a shared Singleton RAF access object is a better choice. You have complete control of access to the file, and no worries about undefined race conditions.
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Would this be a good test for sharing file pointers?


I ran this on WinXP and as expect got the correct file pointers back for each RAF. I've not been able to discover anything conclusive about multi RAF objects pointing to the same file. I'll probably document this in my choices and assume that each RAF has its own file pointer.

I'm gonna stick with my pool implementation unless someone can come up with some conclusive evidence not to use one.
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Arun,

Thanks for the addShutdownHook() tip.

My read/write lock isn't really a physical lock on the file. I read about using the FileChannel (which is part of NIO, so not sure it can be used anyway) and this contains locking methods. However, this is for only locking against separate processes accessing parts of a file, so is not required for our assignment. So my read/write lock is more of a logical lock.

What I've done with the read/write lock is similar to the lock/unlock except I set it when I'm about it either read from or write to a record.

For each record I implement a queue and when a read or write lock request is made on the record I add the object that made the request to queue along with the type of lock required.

I then make the following tests:

If it is a Read Lock, I test to see if there are objects infront of the object wait for a Write lock, if there is, I wait, if not I process the read.

If it is a Write Lock, I test to see if the Write Lock is at the front of the queue. If it isn't I wait.

After either reading or writing to the record, I then call a releaseLock method, which removes the object from the queue and notifies all other records in the queue to test to see if they can leave their waiting state. I perform the synchronization on the queue.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic