Win a copy of 97 Things Every Java Programmer Should Know this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

reserveDVD() one ReentrantLock or a List of ReentrantLocks

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 (??)



Posts: 11604
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • 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,
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.
So I left, I came home, and I ate some pie. And then I read this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic