• 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 ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

lock() / unlock() really needed in "non-networked mode"?

Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all
One further post to the never-ending locking-unlocking story! ;-)
Two questions:
1. I wonder if record locking is really needed if the client runs in the local ("non-networked") mode? Since there is only one client, I think it doesn't make sense to lock records, or do I miss something?
Therefore, in my solution the 'lock()' and 'unlock()' methods of the 'Data' class remain empty. I implemented locking & unlocking in the Connection class (a UnicastRemoteObject) which implements the DataAcess interface and calls the methods of the Data class. I didn't implement the 'lock()' and 'unlock()' methods in the 'Data' class itself because any attempt to access the clientId (stored in the Connection class) ended in a ugly design.
-> Any opinions about this?

2. Assume, you're starting two or more clients in the local ("non-networked") mode. All clients operate on the same "db.db" file, ie. every client opens that file for reading and writing.
If two client-processes perform a write operation on the file at the same time, they will corrupt the "db.db" file (in the worst case) - isn't it?
-> Can anyone tell me if anything should be done to avoid this situation?
PS: For completeness, same problem also occurs if two or more servers operate on the same file or if a client in the "non-networked mode" is started on the same db.db file where a server is already running.
Daniel Brugger
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter den Haan, you just gave the answer to my first question two hours before (shame on me, sorry...)

For example, do not assume that lock() and unlock() need to be implemented on Data. They are fine as they are. Yes, that means empty methods. Really! If you want to, you can flesh them out a bit by adding validation code for the record number, but the lock() and unlock() methods in Data do not need to implement locking at all.

At least: if two people find the same solution, it can't be that bad!
Has my second question also also been discussed in the recent past?
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Regarding your second question -- yes, they would corrupt the file. It's possible to do something about this (using a lock file) but for myself I decided that this was out of scope: there's nothing of the kind in the basic Data class that you have been given.
- Peter
[ April 14, 2002: Message edited by: Peter den Haan ]
Paper jam tastes about as you would expect. Try some on this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic