• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking Mechanism

 
Mark Smyth
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just wanted to solicit a few comments on the latest version of my data class and locking strategy.

First up is the main lock unlock methods. These are implemented using a private LockManager which maps a record number to the thread reference which has aquired the lock. The update and delete methods make sure that the same thread that locked the record is actually doing the updating.

All of the public methods create a new RandomAccessFile object when they are called so that there is no synchronization issues on a singleRAF object.

I also have a business layer Facade with book() and search() methods that ensure that the lock / update / unlock sequence is adhered to.

As there is a increased danger of dirty reads due to there being numerous active RAF objects I have decided to implement a simple read-write monitor to ensure that this doesn't happen. This monitor basically allows multiple readers if there are no writers writing or less that 2 writers waiting to write. Writers are allowed to proceed if there are no readers currently reading. Multiple writers are allowed as the logical record locking ensures that there are no two threads writing to the same record at the same time.

I have two private methods readRecord and writeRecord which do the low level reading and writing for the public methods such as create, read, find delete etc. It is in these two methods that the monitor is used in.









I think that this approach is safe from deadlock but I am not entirely certain. Was wondering if anyone has any comments?
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mark.

When I started to work on my assignment I did the same thing. I created a transaction isolation mechanism.

I used to call the methods beginTransaction() and endTransaction().

The beginTransaction checked the transaction status of a record, and it allowed concurrent reads, while it only allow a write transaction per record.

The endTransaction method, simply released the transaction.

At the end, and after talking with a few people in this forum, I realized that maybe that complications were not necessary. This is not a requirement of the database implementation. So I changed my desing and documented this deficiency in the design choices file.

Anyway, implementing this transaction isolation mechanism is complicated I if you do it wrong you could be getting a bad grade for your database implementation. So be careful. Above all a problem I perceived was related with the transaction fairnes. Upon a huge ammount of database reads, the write transactions had a lot of possibilities of never getting executed.

Therefore if this is your design I would suggest you to take care of this issue.
 
Mark Smyth
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Edwin Dalorzo:
Hi Mark.

When I started to work on my assignment I did the same thing. I created a transaction isolation mechanism.

I used to call the methods beginTransaction() and endTransaction().

The beginTransaction checked the transaction status of a record, and it allowed concurrent reads, while it only allow a write transaction per record.

The endTransaction method, simply released the transaction.

At the end, and after talking with a few people in this forum, I realized that maybe that complications were not necessary. This is not a requirement of the database implementation. So I changed my desing and documented this deficiency in the design choices file.

Anyway, implementing this transaction isolation mechanism is complicated I if you do it wrong you could be getting a bad grade for your database implementation. So be careful. Above all a problem I perceived was related with the transaction fairnes. Upon a huge ammount of database reads, the write transactions had a lot of possibilities of never getting executed.

Therefore if this is your design I would suggest you to take care of this issue.


I am very concious of losing marks for poorly implementing something that isn't even in the specs. Especially should a marker not like my implementation.

My design is not as complex as yours in that it has no concept of records, only that readers and writers should not mix together. The assumption being that the writers will obey the higher level record locking scheme.

In my design the writers can be favoured so that that if more than maxWaiting number of writers are waiting no more readers will be allowed through, thus avoiding the starvation of writer threads.

Also having tested it it does seem that deadlock is not an issue as the only thing that can stop a write taking place is a read not another write, which can of course never be the holder of the lock on a record.

However I am probably gonna drop it because of the above reason but also that it may be against the the keep it simple instruction.

BTW do you think the multiple RAF object approach is ok?

Thanks,
Mark.

[ October 25, 2006: Message edited by: Mark Smyth ]
[ October 25, 2006: Message edited by: Mark Smyth ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic