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)
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!