Do I need WeakReferences for Locking?

[Robert Konigsberg]

I worked on a multithreaded server using TCP/IP (not RMI) where the socket was converted to a BufferedInputStream, etc.

i.e.

func(Socket socket)
{
BufferedInputStream _in = new BufferedInputStream(socket.getInputStream());
}
...
while(true)
{
   ...
   char c = _in.read();
}

Since BufferedInputStream.read throws an IOException when the client shuts down, I can very easily operate on a shut-down client, and therefore, do not need to work with weak references, yes?

If my logic is correct, then my understanding is that either you:

Use RMI and Weak References

Use Sockets and catch IOException

Am I wrong?

PS Second post and I figured out the tags!

[ June 24, 2004: Message edited by: Robert Konigsberg ]
[ June 24, 2004: Message edited by: Robert Konigsberg ]

[Eben Hewitt]

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).

[Robert Konigsberg]

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?

[Eben Hewitt]

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.

[Robert Konigsberg]

Yes, I would like to read about that. Thanks.

Rob

[Andrew Monkhouse]

Hi Robert,

The topic is "Should lock methods be callable by the client".

Some general comments:

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).

Regards, Andrew