I throw a runtime LockException (defined by me) in the case of that InterruptedException you catch in the lock.
In addition, I am interested to hear your motivations for the current system time as a choice for a cookie. Are you sure that your cookies are guaranteed to be unique between the clients? It also looks like that the cookie will change all the time for a given client, which may be a problem is debugging/diagnosing the potential problems.
- Phil, Vlad, Jim and Max slogged it out in thread 5641. In the previous FBN assignment, there are some possible designs that need a notifyAll for lock().
[Terry]:I think Phil may have been a part of that discussion ..
I don't understand why neither notify() nor notifyAll() is needed in this lock method. If remove the notify method, then all other threads have to wait because lockedRecNumbers (I think this object is declared as static) is being locked.
I do all my synchronization like this throughout my Data class. I.e. I/O operations are done in synchronized blocks on the raf, and locking / locking checks are synchronized on the locking HashMap. These always follow one after the other in any one method. They are never synchronized at the same time in the same method. Not nested.
Now my question is, will the way I did this be OK, or might it cause problems?
I think it's fine, because locking doesn't really have any thing to do with I/O directly.
So I guess if after wait is over, and just before locking the record, you might need to check if the record is valid or not.
How to fine thread 5641, 5698?