Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

reserveDVD() one ReentrantLock or a List of ReentrantLocks

 
Bart Lamberigts
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

for implementing locking for update/release, the book (SCJD Exam with J2SE 5) uses one ReentrantLock() object, and a Condition (lockReleased) (see book pg 154).

However, my solution is different, and I wanted to know if this is better/worse...


I have a list of Lock objects, one for each 'DVD'.

my method looks like this:



I unit tested my solution, and it seems to work. The only concern I currently have is that such a list of Locks could take a big chunk of RAM memory (??)

regards,

Bart

 
Roel De Nijs
Sheriff
Posts: 9828
103
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bart,

Seems fine by me, but I didn't use the new concurrency api. I coded my Data class using synchronized, wait and notifyAll.

I think the main question you have to ask yourself why you would opt for this approach, because you have to justify your decision in the choices.txt file. And indeed if your database has 10000 'DVDs', you will need a lot of RAM memory. This might be a drawback that you have to consider and address in this file. I for example used a record cache, which can have a memory issue too. So I documented that decision and proposed some alternatives/solutions to solve this memory issue.

And based on your name I would guess you are from Belgium too (could be the netherlands too)

Kind regards,
Roel
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would see in this approach that it has the advantage that each row can be acquired separately and independently of other clients, whereas with single synchronized with waits / notifyAlls you are locking the whole Data class from other clients. When coded correctly, when there are thousands concurrent users, that lock and unlock like fierce beasts, this could have huge performance advantage. You could even go further and use read / write locks for lock map readers and writers probably.
Ram is cheap, user experience is not. Still, such access to the lock map / collection has to be synchronized itself.
I didn't even think of that approach, I opted for the simplest one (just like Roels), thanks for your post.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic