Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why use cookie and strange locking scheme

 
Robert Ooster
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have looked at all the questions about locking and reading and writing to the db file. And this post is exactly what I wanted to ask:
http://www.coderanch.com/t/186563/java-developer-SCJD/certification/singleton-vs-multiton-data-object
The answers is performance.

But then I ask, how can this be a performance hit? In my assignment it says:
"You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server."

So there is only one object accessing the db file, that is where you can get a performance hit. But you only have one db file. So multiple object accessing one file, or one object accessing one file doesn't matter at all.

Why can't I just make the read, update and delete operations synchronized? Wy this scheme with locking cookies? Is there any good material on the net that explains this and the various other locking stuff?
R
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Robert Ooster:

Why can't I just make the read, update and delete operations synchronized? Wy this scheme with locking cookies? Is there any good material on the net that explains this and the various other locking stuff?
R


I think you can make them synchronized, however all this will do is ensure that only a single thread is running in the methods..

You still need to handle lock/unlock (with cookies depending on your assignment). The fact that only 1 thread is running in read/update/delete doesn't change the fact that the records must be lock/unlock.

The cookie is a mean to make sure that only the owner of the record can update/delete.

In order to allow concurrent read/update/delete I did not use synchronized methods...

Hope this helps
Alex
[ April 03, 2008: Message edited by: Alex Belisle Turcot ]
 
Robert Ooster
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Alex, I am starting to see some little light on the subject. Is there any book about this? I could not find a decent description on the internet.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic