Win a copy of Hands On Software Engineering with Python this week in the Jython/Python forum!

Daniel Brugger

+ Follow
since Dec 13, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Daniel Brugger

Hi Jason

My question is: Should the syn keyword be on LockMan's lock() method,

yes, I think it's the best place

inside LockMan's code block,

you could, but what would it help?

on ConnImpl's lock() method,

no, you were locking on the wrong object

or inside ConnImpl's lock() code block?

you could but I wouldn't suggest that

Does it matter?

yes, it does!
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?
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.
ever played with the memory options of the JVM?
for the java command in jdk 1.1.x they were:
-mxNNm (to set heap size to NN MB)
-msNNm (to set stack size to NN MB)
for java2, i'm not sure but i think they changed - have a look at the manpages!
17 years ago
if you're going to distribute a professional software, have a look at Zero G's "InstallAnywhere" ( I'd say this is THE Java installer
17 years ago