Is there logging or other variably present software paths that may have inadvertently done toString or something else which made a remote callto the lease object and could cause the test to work in such cases?
Sent from my iPhone On Oct 27, 2010, at 5:02 PM, Patricia Shanahan <[email protected]> wrote: > Test com/sun/jini/test/impl/outrigger/leasing/UseTxnMgrSpaceLeaseTest.td > complains because a JavaSpace lets it go on using a Transaction for writes > after the Transaction's lease has expired. > > The JavaSpace implementation, com.sun.jini.outrigger.OutriggerServerImpl > joins and caches the Transaction the first time it is asked to do an > operation with it. It does not repeat the join, or any other Transaction > operation, when doing another write for a Transaction is has already joined, > so it does not find out about the Transaction's lease termination. > > I have tentatively reached the conclusion that the Outrigger implementation > is reasonable. If the JavaSpace caller wants to know whether the transaction > is still active, the caller can itself do a getState() test. There is no > reason to force the equivalent of a getState() at each JavaSpace write for > the transaction. > > In normal use, the caller will issue a limited number of operations > associated with the transaction, and then do a commit or abort. The lease > should be long enough that there is a high probability of finishing those > operations within the lease time. At the time of the commit or abort, it will > get an UnknownTransactionException if the transaction has been discarded due > to lease expiration. The caller cannot be sure the operations will take > effect until a successful commit. > > I think the failing test requires something that is neither specified nor > logically necessary, and propose deleting it from the test program. > > Any opinions? > > Patricia
