I used RMI and did not use weak refrences. My lock was stored as part of an in-memory record object in a singleton list. All locking and unlocking was done on the server. The way I figure, it doesn't matter who has the lock, just that the same person who locks it unlocks it.
Because it could happen that a user gets a lock, then calls some method that modifies the database and then an exception is thrown, I always unlock in a finally clause. So there won't be orphans. If the first two things happen (lock/modifying method call) then the client JVM crashes before reaching the finally block, I document that I don't handle that, but I do provide a pretty button for restarting the server to reset an orphaned lock. I think it is okay, since I don't expect that to happen often, and it is clearly documented.
I deal with client identification with a callback when in networked mode and blow it off it local mode. But that for a different reason (event notification).
Eben Hewitt. SCJP, SCWCD, SCJD, SCJWSD for JEE 5, TOGAF 8 Certified Architect, author of Java SOA Cookbook (O'Reilly, 2009) and contributor to 97 Things Every Software Architect Should Know
Joined: Jun 23, 2004
Perhaps I am a bit obtuse, but do you really think the lock/operation/unlock needs to occur on the client?
Why wouldn't it be on the server?
Joined: Apr 16, 2004
Hi Robert Perhaps my answer was rambling and unclear, for which I apologize--I was very tired. I agree with you totally. I don't think that lock and unlock should happen on the client. I think it should happen on the server and the client should be shielded from that totally.
But there has been considerable debate on that matter in this forum, and it is very interesting. There are good arguments both ways. I don't have the link handy right now, but there is one discussion in particular that was quite long; maybe someone else can point us to it.
But if I am not mistaken, the WeakReferences business is popular with the Lock on the Client Crowd, so I (apparently wrongly) assumed that's what you were interested in.
While the title suggests that this is talking about the lock methods, it is really talking about exposing all the methods of Data class to the client.
There is a lot of discussion about "two tier" versus "three tier" solutions. An alternative way of discussing this (used about page 3 of the discussion) is "thick client" versus "thin client". These discussions are all about whether the business logic should be on the client (fat client or two tier) or should be on the server / middleware (thin client / three tier).
At the end of the discussions you will find that candidates have passed no matter whether they exposed the Data class' methods to the client or not. So it does appear to be just a design decision which you can make (and justify in your choices file).