Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Daniel Brugger
Greenhorn
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.
Thx
Daniel
 
Daniel Brugger
Greenhorn
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?
Daniel
 
Peter den Haan
author
Ranch Hand
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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic