Forums Register Login

Is it ok to NOT taking care of client crash?

+Pie Number of slices to send: Send
Hi Ranchers,

I do not want to take of client crash in my code, because it is not required in the docs and the chance for one client to crash with a locked record is pretty low.

Is it ok? Anybody passed the exam without taking care of it?

Thanks.

Cheers,
Zhang Jin
+Pie Number of slices to send: Send
Hi Jin,

I didn't implement any checks for client-crashing in my server code and didn't lose any marks for that. However I have mentioned this in my design choices document.

-- Serkan
+Pie Number of slices to send: Send
If you mean "dead cliens", ie when client crashes while record is locked, then it is better to handle such situation. In my design I handled it and get 80 / 80 on locking mechanism.
[ June 04, 2004: Message edited by: Denis Spirin ]
+Pie Number of slices to send: Send
Hi,

Thanks both of you!

80/80, wow! Pass is enough to me I think. Do not want to spend too much time on it. So... Serkan, may I know your score for the locking portion?

Cheers,
Zhang Jin
+Pie Number of slices to send: Send
I think that to max out in the locking area you MUST have a mechanism that will prevent the locking of a record if the client crashes out. I did this by using a thin client design with the unlock on the server in a finally block.

Also document your descision.

Steve.
(I too got 80/80 locking)
+Pie Number of slices to send: Send
Can anyone tell me how it is best to implement this client crash issue? I'm pretty stuck.

Thanx for any help.

Jarvis
+Pie Number of slices to send: Send
Hi Jarvis,

If you implement a thin client (so the client calls a "book" method on the server which does the whole "lock - verify - update - unlock" process, then you should never need to deal with dead clients.

However if, like me, you think the client should be handling the booking process, then there is the potential for a client to die before disconnecting. (For more on the whole fat client / thin client issue, see the long thread "Should lock methods be callable by the client").

The easiest ways to handle this involve setting up a connection factory on the server. This way, each client will have a unique instance of the remote class which provides all the functionality. You then have two ways of handling client death:
  • Implement the Unreferenced interface, so that the instance of your remote class will eventually be notified if the client dies - you can then perform any clean up operations.
  • Use the instance of the remote object as the key in a WeakHashMap (with the object in the map being the lock), so that when the client dies, the lock will automagically be removed from the map (you may want to have an extra thread monitoring the status of the map).



  • I have deliberately not gone into detail on any of these - have a think about them, and see if you can work out how to move forward with them.

    Regards, Andrew
    +Pie Number of slices to send: Send
     

    Originally posted by Jin Zhang:
    Hi,

    Thanks both of you!

    80/80, wow! Pass is enough to me I think. Do not want to spend too much time on it. So... Serkan, may I know your score for the locking portion?

    Cheers,
    Zhang Jin



    I've got 80/80 as well (without crashed client detection).
    [ June 11, 2004: Message edited by: Serkan Yazici ]
    You didn't tell me he was so big. Unlike this tiny ad:
    a bit of art, as a gift, the permaculture playing cards
    https://gardener-gift.com


    reply
    reply
    This thread has been viewed 1335 times.
    Similar Threads
    Is this simplest searching algorithm ok?
    is Unreferenced a bad idea ?
    URLyBird 1.1.3: Design reassurance.
    NX: Database Wizardry (or lack thereof)
    consumes no CPU cycles?
    More...

    All times above are in ranch (not your local) time.
    The current ranch time is
    Mar 28, 2024 10:29:36.