Lease pattern

[Charles Dupin]

Hi,
Would you recommend implementation of a leasing system to track client connection loss from server side in order to clean the locking tables appropriately.
If yes would you use net.jini.core.lease.*, or would you implement something from scratch.
Many thanks,
Charles.

[Mag Hoehme]

Hi Charles,
I'd be careful with anything beyond the scope of core Java. And packages such as net.jini... sound quite exotic to me! The assignment is about solving a problem with standard java technology. Therefore I'd advise you to develop something from scratch (besides: I don't know what "leasing pattern" means - could you explain that to me?)
Thanks!

[Charles Dupin]

Hi Mag,
The leasing pattern: When a client wants to obtain some resource from the server (a lock for example) it must first acquire a Lease (a permission) from the server. This Lease is valid for a certain amount of time. The client must renew the lease before its expiration if it wants to keep the resource.
If the client fails to renew the lease, the server can take action pertaining to this situation. In our case, the server can free the lock and notifyAll. With this pattern the server can easily detect if the client connection breaks.
This involves quite a lot of nice thread programming of course.
Regards,
Charles.

[Pete Lyons]

Charles,
Remember that no timeouts or extra complexity are specified in the requirements. If you give each remote client a unique connection object, you can use RMI's built in unreferenced() functionality to achieve a simple solution for dealing with clients that disconnect while holding one or more locks. Anything beyond that is overkill and just more chance for mistakes. Also, the assignment must be made up entirely of classes from java.* and suncertify.* that are either provided with the JDK or written by you, so any third party classes are strictly off limits.
Pete

[Thomas Fly]

Pete is absolutely correct: use of net.jini.core.lease.*, com.borland.jbcl.layout.*, and the like, falls under this stern caveat:

Target Platform
Throughout this exercise, you must use exclusively the Java 2 platform. You are not required to develop your code using any particular implementation of the Java 2 platform, but the submission that you return must have been tested and shown to work under a production (not development) version of the Sun Microsystems' Java 2 platform.
Failure to adhere to these directions will result in automatic failure

On the other hand, I did choose to implement a 60 second lock-lease (configurable in my config.xml file ), mostly to take a small step in the direction of database transaction-rollback functionality, and to demonstrate the "gracefulness" of my server shutdown.
Every "spiffy" feature you add must be adequately commented, however, or you'll end up with a score of 154, like Michael Morris :roll:

[Dave Teare]

Just a thought off the top of my head: is the lock and unlock methods the client class calls not essentially an implementation of the lease pattern? The call to lock provides the client the right (i.e. lease) to use the record for X amount of time. Of course, unlock gives up the lease.
If we decided to add the lease pattern on top of the lock/unlock methods, we would essentially have a double lock check; namely:

    lease(recordNum);
      lock(recordNum);
      unlock(recordNum);
    release(recordNum);

The double 'lock' is worriesome to me. So my thought was to say in my DESIGN_DECISIONS.txt that the lock/unlock mechanism follows the lease pattern, with the caveat that clients cannot renew a lease. The server researves the right to revoke a clients' lease on any lock if the lease period expires.
Comments?
--Dave.

[Thomas Fly]

The usual approach to locking is to attach a ClientID to a record, using HashMap. Instead, I use a class that contains the ClientID along with a timestamp & progress counter, which can be checked by the server to decide whether or not to revoke the lock held by a given client.
It's hard to say how big a problem a "stalled" (as opposed to "dead") client would really be in a production environment, however.
There's really not even much of a good reason to attach a ClientID to the locks, except to handle the infrequent occurence of a client dying just after acquiring a lock- but if you're writing an online banking application...

[Charles Dupin]

Dave,
I do not consider doing a leasing pattern like the one you described here :
lease(recordNum);
lock(recordNum);
unlock(recordNum);
release(recordNum);
Leasing and locking done by two different threads on both sides.
lets say leases are valid 5 seconds
Client X:
Th1---------------------------- Th2---------------
t1-- ask for a lease (5 secs)
t2-- get it tell thread 2 to work --- lock
t3-- renew the lease (5 secs) -----read write
t4-------------------------------- unlock
t5-- quit leasing
t6--
Server:
Th1------------------------- Th2---------------
t1++ give the lease to X(5 secs)
t2-- -------------------------------- check all leases
t3++ give the lease to X(5 secs)
t4-- ----------------------------- --- check all leases
t5--
t6-- -------------------------------- --- find dead lease of X ( > 5 secs), check lock table
for X dead locks

Regards. :roll:
[ November 08, 2002: Message edited by: Charles Dupin ]
[ November 08, 2002: Message edited by: Charles Dupin ]
[ November 08, 2002: Message edited by: Charles Dupin ]

[Charles Dupin]

Sorry for the poor readability of the previous message, I dont know how to edit tables with this bulletin board.
Regards
Charles

[Peter den Haan]

Re: tables -- anything you put between [ CODE ] tags will be displayed using a fixed-with font. So you can use good oldfashioned ASCII art.
- Peter

[Thomas Fly]

Originally posted by Peter den Haan:
Re: tables -- anything you put between [ CODE ] tags will be displayed using a fixed-with font. So you can use good oldfashioned ASCII art.
- Peter

Good point. Which raises the more interesting question as to whether or not the week should be changed to include 2 consecutive Saturdays, and a tunnel bored through the earth to connect Australia & North America?

[Charles Dupin]

to Peter,
I could not make the [CODE] stuff working.
Sorry.

[Thomas Fly]

Just use the CODE button:

[Charles Dupin]

Client X:                                                             
------------Thread 1-------------    -----Thread 2-----------            
t1      ask for a lease (5 secs)                                         
t2      get it tell Thread 2 to work       
t3                                         lock
t4     renew the lease (5 secs)           
t5                                         read write
t6                                         unlock
t7      quit leasing
t8 
Server:
------------Thread 1-------------    -----Thread 2-----------            
t1+ give the lease to Client X
t2+                                      check all leases
t4+ give the lease to Client X
t5+                                      check all leases
t6 
t7+                                    find dead lease of X ( > 5 secs), 
                                       check lock table for X dead locks