• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

threadsafe locking

 
jennifer truong
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seems to me that the locking could be made threadsafe without using the synchronized keyword. If, for instance, the locked record numbers are tracked in a Vector, then the code should be threadsafe because Vectors are already synchronized. The API points out this feature of the Vector class. Any thoughts out there on this?
Also, I've been reading that people seem to think that locking is not needed in local mode. This appears false to me. Local mode does not preclude having multiple users, and all the users could be using the same database file.

 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by jennifer truong:
Seems to me that the locking could be made threadsafe without using the synchronized keyword. If, for instance, the locked record numbers are tracked in a Vector, then the code should be threadsafe because Vectors are already synchronized. The API points out this feature of the Vector class. Any thoughts out there on this?
Plenty. It's a trap. Don't fall into it. The fact that a Vector is a threadsafe object means that multi-threaded access will not break the internal consistency or external contracts of the Vector. No more, no less. More specifically, it does not mean that classes using the Vector will be threadsafe, and I guarantee you that a lock manager without synchronization will not be threadsafe even though it uses a Vector.
When developing multi-threaded code, too many developers start using threadsafe objects all over the place (wrong) and assume the end result will therefore be threadsafe (bzzzt, thanks for playing, you're out of business).
My recommendation is to work out the logic for your lock manager without making any assumptions about the thread-safety of your lock set. Once that has been done, you know what chunks of code needs to execute in a synchronized block and you can establish whether a synchronized data structure actually buys you anything. The answer is probably "no".
Also, I've been reading that people seem to think that locking is not needed in local mode. This appears false to me. Local mode does not preclude having multiple users, and all the users could be using the same database file.
Wish that were true. Unfortunately, Java does not give you any access to the operating system's file locking features. As a consequence there is no safe way of accessing a file in read/write mode from multiple processes - a single file should only be accessed by a single copy of Data. This makes implementing locks in local mode a pointless exercise.
- Peter

[This message has been edited by Peter den Haan (edited October 01, 2001).]
[This message has been edited by Peter den Haan (edited October 01, 2001).]
 
Siddharth Mehrotra
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, I've been reading that people seem to think that locking is not needed in local mode. This appears false to me. Local mode does not preclude having multiple users, and all the users could be using the same database file.
Wish that were true. Unfortunately, Java does not give you any access to the operating system's file locking features. As a consequence there is no safe way of accessing a file in read/write mode from multiple processes - a single file should only be accessed by a single copy of Data. This makes implementing locks in local mode a pointless exercise.
- Peter

[This message has been edited by Peter den Haan (edited October 01, 2001).]
[This message has been edited by Peter den Haan (edited October 01, 2001).][/B]

can you put some more light into the above topic..
as to why locking in a local mode is a pointless excercise
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Siddharth Mehrotra:
can you put some more light into the above topic..
as to why locking in a local mode is a pointless excercise
In local mode, the database is single-user, so there is no-one else who could possibly access "your" records. Unless you want to work with multiple threads within the same JVM that are contending for row locks, there is no point in implementing any locking code.
- Peter
 
Siddharth Mehrotra
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter den Haan:

In local mode, the database is single-user, so there is no-one else who could possibly access "your" records. Unless you want to work with multiple threads within the same JVM that are contending for row locks, there is no point in implementing any locking code.
- Peter

peter just see the state below.
if i have a person who is sitting on ther server machine, so he will access the data in local mode.
but as the m/c is a server there will be other systems trying to connect to it via RMI or any other mechanism.
In this case we would like to have a locking mechanism in local mode also.
dont you think so
------------------
Sid

[This message has been edited by Siddharth Mehrotra (edited October 08, 2001).]
 
Ian B Anderson
Ranch Hand
Posts: 275
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Siddharth,
Wouldn't the person who is sitting on the server machine be running a local connection, i.e. no remote connection-handling no RMI registry, not exporting any remote objects. Even if someone tried to connect there would be nothing to connect to.
I think in the specification one of the conditions for local mode is that no sockets are created therefore nobody could connect when running in local mode.
Ian
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Siddharth Mehrotra:
if i have a person who is sitting on ther server machine, so he will access the data in local mode.
but as the m/c is a server there will be other systems trying to connect to it via RMI or any other mechanism.
That's impossible.
As Ian points out, in local mode you may not create any sockets so you cannot act as a server at the same time. That would be a serious confusion of responsibilities anyway - the server should be a self-contained application and not be a client as well.
In case you are thinking about running a server against the same database file, this is not possible either. To allow two processes safe r/w access to the same file, you need access to the operating system's file locking features. Java does not grant such access.
- Peter
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In theory it's possible for two DB server to access the same file in squential manner by opening it and closing when an operation is complete. So even though ugly, it is possible.
What is not possible is share lock information between two data servers, unless you store it in another file or db. That's also ugly.
So,in local mode, your server runs in its own JVM therefore it's the only components accessing db.db, which is safe by definition.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic