• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Dead clients and the locks they still hold

 
Jared Cope
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am wondering if people handle the situation when a client acquires a lock for a record (in order to update or delete) and then the client crashes suddenly without releasing the lock (power failure, application process killed etc). In this case, no other client will ever be able to obtain the lock for this record.

Does anyone have a mechanism in place to check for this condition from the server, or is it too much 'sugar coating' for this assignment?

This condition is not mentioned specifically in my spec, but I am wondering if it is an implied "must" requirement, or just something nice to have.

Cheers, Jared.
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Helo Jared,
Locks belonging to crashed clients are known as "stale locks" you can search the formum for it.
You will find lots of discussion.

these are some ways to solve the problem:
- Timeouts
- Weak references
- Connection factory + Unference implementation
- Sockets based solution

Regards,

PD:
Still waiting your comments at RMI NAT callback thread...
 
Jared Cope
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Originally posted by Oricio Ocle:
Helo Jared,
Locks belonging to crashed clients are known as "stale locks" you can search the formum for it


Okay, will do. And I don't really have anymore comments about the NAT callback thread. I think it would work, but don't have the drive/ambition/time to change what we already have in production. If I do, I'll certainly tell you how I go.

Cheers, Jared.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic