aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Do I need WeakReferences for Locking? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Do I need WeakReferences for Locking?" Watch "Do I need WeakReferences for Locking?" New topic
Author

Do I need WeakReferences for Locking?

Robert Konigsberg
Ranch Hand

Joined: Jun 23, 2004
Posts: 172
I worked on a multithreaded server using TCP/IP (not RMI) where the socket was converted to a BufferedInputStream, etc.

i.e.


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 ]

    SCJP 1.4 (91%)<br />SCJD 1.4 (376/400, 94%)
    Eben Hewitt
    Author
    Ranch Hand

    Joined: Apr 16, 2004
    Posts: 36
    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
    Robert Konigsberg
    Ranch Hand

    Joined: Jun 23, 2004
    Posts: 172
    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
    Author
    Ranch Hand

    Joined: Apr 16, 2004
    Posts: 36
    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
    Ranch Hand

    Joined: Jun 23, 2004
    Posts: 172
    Yes, I would like to read about that. Thanks.

    Rob
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11525
        
    100

    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


    The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Do I need WeakReferences for Locking?