Hi Thomas,
Welcome to JavaRanch and this forum.
"Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available."
Does this mean that I cannot perform any polling of the users waiting on a lock every N seconds, or can the wait timeout without the resource becoming available?
Cannot is a bit strong here - the instructions do not specify a "must" condition, but rather a "should" condition. So you could poll the users waiting on the lock every N seconds if you really wanted to.
Why do you want to though?
Is it acceptable to lock the entire database while operating locally, even if there are remote users already on the system, when the remote users are not holding any locks?
This scenario should never occur. Check your instructions for text along the lines of "
You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server". In other words, you cannot be running locally (
java -jar runme.jar alone) at the same time as you are allowing remote users access by running a server (java -jar server).
Even if you could, I do agree with Darya that logically locking the entire database is not something you want to be doing - you are blocking all the other users.
If you are talking about physical locking (ensuring that only one thread is physically accessing the data file at any given time), then you are going to have to perform that lock in multi user mode, and since the same Data class will be used for both multi user and single user, you will, by default, lock the data file in single user mode
.
Can the Server already be started on the “local server” before any remote users try to log in? I didn’t think it was possible to start another process on a remote machine.
As Darya said, you have to start the Server from the command line. So, yes, it can be started before any remote users try to log in.
And you are correct - it is not possible to remotely start an application. (There are all sorts of caveats on this, such as having a "master server" start minor servers when they receive a given command (think of remote control of a J2EE application server) or using inetd on a Unix server to start a Java process. But none of these caveats apply to the
SCJD assignment).
I am using List recordLockList = Collections.synchronizedList(new ArrayList)) as a thread safe was to keep my RecordLock objects (record number, user session id), a J2EE friend of mine suggested that I keep an external file and write locked records into it, which way is better, and am I allowed to even write to an external file?
I think that you would be allowed to write an external file if you wanted to. But what benefit will it give you?
One possible reason could be that it would allow you to determine which records were locked following an application or system crash. However if the application or system crashed, then the clients would be disconnected anyway, so this would be of little value (IMHO).
If the data you were storing in your collection was large, then you could (theoretically) store more of this data on the hard drive. But take a look at what you are storing in your collection - is it really so large? How many locks would you need to be storing in the collection before you started to be concerned about the memory usage?
What other reasons do you (or your friend) have for suggesting storing to file?
Just on the subject of your synchronized access to the collection - presumably you are verifying that a RecordLock object does not exist in the collection for the record you are trying to add before you perform the actual adding. If so, would you agree that the two steps you are performing on the collection should be atomic? If so, does it make sense for the collection itself to be synchronized?
Regards, Andrew
. In my case, I am also afraid to kiss my 420 Euro. 
