Still working on my locking part, more specifically the bit below. I thought I'd share my insights and see if anyone had other thoughts on the matter.
I've been investigating the various solutions to implementing these messages and come up with the convention that "is already locked by a different client" would have to mean that the same thread should not block if it repeatedly tried to lock the same record - and this makes good sense and has been mentioned in other posts as well.
This requires several things:
- "lock -> process -> unlock" should occur in same thread, or "client identification" might be hard.
- If using RMI, thread pooling should be disabled (it is by default, but it's an important point), otherwise two clients could potentially get the same thread id. This is partially mitigated by the above point, since it'd be fair to assume that RMI doesn't reuse threads until their request is served.
Now, I've only been focusing on the networked part with threads and RMI - and the above seems to be pretty common in the other posts here... But allowing multiple locks in the same thread not to block actually has implications for standalone mode. I'd say it's a fair assumption to believe noone (or very few) are making their standalone mode multi-threaded. So the locking mechanism will have absolutely no affect in standalone mode - since it will always be the same thread.
Well, just my thoughts on the matter :-) Comments are welcome.