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

Locking info: a DB field vs. in-memory

 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gentlemen,
the way I see it I have two options of implementing DB locks:
1. add another field into the DB and use it as a lock-indicator.
This approach requires modification of DB scheme.
2. DB Server may have in-memory information about locked records. This approach does not require modification of DB scheme and makes it easy to synchronize locking.
Any other ways?
Thoughts?
Thanks
 
Nigel Browne
Ranch Hand
Posts: 703
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I see it we need two variables a hashtable and a boolean. These can be: 1 added to the Data class i.e modification.
2 an inner class can hold them and the locking methods refer to the inner class.
3 The Data class can be subclassed.
I am using method one as I beleive that locking is an integral part of a database. As this class performs the functionality for the database I feel this is an acceptable solution, even if locking is not needed to be implemented in single user mode it does no harm being there.
I would welcome discussion on this.
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nigel,
you identified a number of ways to implement an in-memory locking mechanism.
Like I mentioned, you could achieve the same by modifying the database scheme and having an extra field to indicate lock-status of a record. An advantage of this would be persistent locking that survives crash of DBManager (Data.java). I don't really think this projects needs this , but I keep thinking maybe there is another way of implementing locking??
How do Sybase and Oracle do that?
Thanks
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nigel Browne:
I am using method one as I beleive that locking is an integral part of a database. As this class performs the functionality for the database I feel this is an acceptable solution, even if locking is not needed to be implemented in single user mode it does no harm being there.

Arguably, the Data class is responsible for the functionality for the single-user database, and some other class is responsible for adding a multi-user layer on top of Data. In that case, it is the latter and not Data which is responsible for implementing locking. The lock and unlock methods in Data could stay empty.
- Peter
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gennady Shapiro:
How do Sybase and Oracle do that?
In all databases I know, database locks are not persistent - if the database crashes, your locks are gone. This does not apply to optimistic locking which is usually implemented at the application level using a versioning field in the table.
- Peter
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now I am thinking of distributed transaction managers like Weblogic's TM. Those locks have to be persistent somehow.
In any case, that is well beyond this project.
Seems that a simple in-memory locking is the way to go.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic