Forums Register Login
lock() / unlock() really needed in "non-networked mode"?
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.
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?
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 ]
Evacuate the building! Here, take this tiny ad with you:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database

This thread has been viewed 641 times.

All times above are in ranch (not your local) time.
The current ranch time is
Feb 20, 2019 08:39:06.