wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes myThread.isAlive() v.s. WeakReference ? URLyBird 1.2.2 using Socket Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "myThread.isAlive() v.s. WeakReference ? URLyBird 1.2.2 using Socket" Watch "myThread.isAlive() v.s. WeakReference ? URLyBird 1.2.2 using Socket" New topic
Author

myThread.isAlive() v.s. WeakReference ? URLyBird 1.2.2 using Socket

Anusorn Swasdee
Greenhorn

Joined: Nov 04, 2004
Posts: 13
In lock mechanism, if I want to check weather the Object that
lock the record is still alive, what is the better choice -- .isAlive()
or WeakReference?


I've test something with WeakReference



And the Result is..



It disappointed me. The WeakReference Still be there.
Not equal null as it should be.
Which means when I use



It may be no guaranteed that I can detect the lost or disconnect client!


And when I try myThread.isAlive()



The result is ...



Is my understanding is true?

Then, why discussion in this forum choose to use WeakReference?


Waiting for your reply and
Thanks in advance
Anusorn
[ February 15, 2005: Message edited by: Andrew Monkhouse ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Anusorn,

I have put your code between [code] and [/code] UBB tags. Doing so helps preserve indentation, making your code easier to read, which improves your chances of getting a reply.

Two problems with the code you presented:
  • You were not giving the JVM time to run the garbage collector (and/or not explicitly running the garbage collector)
  • You were looking at whether the WeakReference object existed rather than it's referent
  • .

    Take a look at the following code:


    Which, when run, could give the following output (remember the call to gc() is only a request):



    Regards, Andrew


    The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
    Anusorn Swasdee
    Greenhorn

    Joined: Nov 04, 2004
    Posts: 13
    Thank you very much. ^ ^

    Your example does help much. If you don't post, I may still go wrong
    direction.

    Sorry for the bad code layout, next time I will type it in code tag.

    Thanks for your reply.
    from Anusorn.
    Anusorn Swasdee
    Greenhorn

    Joined: Nov 04, 2004
    Posts: 13
    I've run your code and have 2 different results.



    and



    Interesting.

    Do these results mean that the to-be-joined object
    of the running thread may or may not go to dead state
    before doing it's finalize() method?

    Or is it dead already before doing the finalize() method, and
    the wait-to-join thread can decide to change to running state whether
    before or after the finalize() method of the dead thread
    be executed?

    Very detailed example!!!
    Thanks. :-)
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi Anusorn,

    Finalize won't be called until after the thread has finished running.

    My purpose in showing when finalize was run, was to show the correlation between the object being garbage collected and the weak reference referent being cleared.

    Regards, Andrew
    joe lin
    Greenhorn

    Joined: Dec 07, 2004
    Posts: 28
    hi all,
    I think my next question is related to the above content.
    my question is:
    suppose there is a thread which stands for a client and that thread hold a lock on one record(that record exist in the remote server side),but at this
    moment,the client crash!so i want to know,after that client crashed,is that thread which stands for that crashed client still alive?Does that thread still hold the record lock? can use the WeakReference object solve this problem?
    thank you all in advance!


    Looking for better solution...<br />SCJP1.4
    Jamal Freeman
    Greenhorn

    Joined: Mar 01, 2005
    Posts: 1
    suppose there is a thread which stands for a client and that thread hold a lock on one record(that record exist in the remote server side),but at this
    moment,the client crash!so i want to know,after that client crashed,is that thread which stands for that crashed client still alive?Does that thread still hold the record lock? can use the WeakReference object solve this problem?
    thank you all in advance!



    my SCJD implementation-in-progress is socket-based, so when a client dies, its corresponding server-side thread will catch a socketexception and do the necessary cleanup (releasing lock held, etc) just before terminating.
    Frank Hardy
    Greenhorn

    Joined: Aug 17, 2004
    Posts: 13
    Hi Anusorn,

    I've exactly the same assignment but I used an approach which is completely different from yours to deal with "hanging locks".
    In my approach each lock has an expiration time which can be configured. My locks are represented by lock-objects and are managed by a manager instance. Each lock-object gets a timestamp (current system time) when it is created. Each time the lock manager is accessed it will check the timestamp against the current system time. The difference to the timestamp is calculated and when the expiration time limit is exceeded the lock is no longer valid and will be removed or substituded by another one.

    I think this is a very simple and acceptable solution for this problem.

    What do you(others) think?

    Greetz,

    Franky.


    SCJP 1.4
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi Franky,

    In my opinion, since the instructions for the lock method do not mention anything about a timeout, I am not sure that you are implementing the functionality that Sun would like you to implement.

    Regards, Andrew
    Frank Hardy
    Greenhorn

    Joined: Aug 17, 2004
    Posts: 13
    Hi Andrew,

    hmmmm...yes...you're d#mn right.
    Aaah! How could I miss that? I'm thinking too much over that.
    Thanks a lot for your hint.

    But the "hanging lock" problem is noteworthly.
    I've kicked my timer solution. Now I've substituted it by checking the owner thread-object of a lock if it is still alive (fortunatly it was not much effort). Locks that are owned by dead threads will be now removed automatically. This doesn't break the interface contract. As long a thread is alive it will hold its record locks. In the case a Programer (me) has forgotten to unlock the locked records or the thread is killed or dies without unlocking it record locks, the locks will be removed when at least another thread wants to lock the corresponding records.

    Do you(all) think this is that a better solution?

    Greetz,

    Franky.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11404
        
      81

    Hi Franky,

    This could work if you are using sockets (but then again, if you are using sockets, you could use the exception you get on disconnection as a trigger to clean up orphaned locks).

    However if you are using RMI this will not work. Since this topic is talking about using sockets, I will not bore you with the details, however if you are using RMI, you might want to look at the topic "Using Thread ID for lock owner not safe?"

    Regards, Andrew
    Frank Hardy
    Greenhorn

    Joined: Aug 17, 2004
    Posts: 13
    Hi Andrew,

    okay I see. RMI is typically using thread-pooling. And therfore I cannot be sure that the same thread which locked a record does unlock it. Furthermore, the threads in a pool won't die. isAlive() doesn't work at all.
    I think I have to redesign.

    Never mind, design is fun...

    Thanks a huge lot again for your hint.

    Regards,

    Franky.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: myThread.isAlive() v.s. WeakReference ? URLyBird 1.2.2 using Socket
     
    Similar Threads
    Please explain this code
    Thread Question---start()
    Overriding the start method of Thread Class
    Thread memory leak
    Thread Doubt