• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: Locking idea...

 
Rasmus Larsen
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,

I'm working on my B&S SCJD - been reading quite a bit here on the forum about various locking techniques and think I've come up with what I like better.. But just thought I'd run it past you guys... The locking part seems to be the most complicated thing to get right anyways.

I was planning on just using the logical locks on record level (as suggested by the supplied interface) and then have my internal file-db use a read/write lock to order the IO operations.. Does this sound completely off?

I simply cannot see a way to make the file-db thread-safe unless you do some kind of lock on both reads and writes... But atleast this will allow concurrent reads. One operation in particular comes to mind when securing the supplied interfaces.. Consider 2 threads both creating new records as fast as they can... The create method on the interface doesn't require a lock (since no record id exists yet) - so unless there's a "physical" IO lock, this is bound to go wrong...


Gotta love multi-threading

Thanks,
- Rasmus.


PS. I should note that I'm also using a write-through cache that will handle some of the more delicate issues (or atleast minimize them) such as dirty reads.
 
Adrian Engler
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rasmus Larsen:
Hey,

I was planning on just using the logical locks on record level (as suggested by the supplied interface) and then have my internal file-db use a read/write lock to order the IO operations.. Does this sound completely off?

I simply cannot see a way to make the file-db thread-safe unless you do some kind of lock on both reads and writes... But atleast this will allow concurrent reads. One operation in particular comes to mind when securing the supplied interfaces.. Consider 2 threads both creating new records as fast as they can... The create method on the interface doesn't require a lock (since no record id exists yet) - so unless there's a "physical" IO lock, this is bound to go wrong...



Yes, I agree that the locks that have to do with the locking system that is related to the interface provided by Sun is not enough for thread-safe reading and writing. In my version of the assignment, this locking system was mainly used for an optimistic locking system (preventing users from saving records based on stale data), but for thread-safe reading and writing, additional synchronization was required.

With your type of cache, this may be different, but in my implementation, I used a RandomAccessFile, and I had a synchronized block around setting the file pointer and reading/writing - so, even reads were not really parallel. This was not a problem (at least I received maximum points for the locking part) - I think it is a trade-off; a lock for both reading and and writing operations is not a big problem as long as it is kept for a short time (just two statements), but for the other locks that are held for a longer time, I made sure that they are only used when necessary and not for all operations.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic