Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript 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 ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

threadsafe locking

 
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.

 
author
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).]
 
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
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).]
 
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
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
 
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic