HELP! Re: Bug fixing - JavaSpace and Transaction issue

[Patricia Shanahan <pa...@acm.org>]

I've moved on to another javaspace failure, 
com/sun/jini/test/spec/javaspace/conformance/ExpirationNotifyTest.td 
"Not all listeners've got expected number of events."

It appears to be a similar issue. There seems to be a general 
disagreement between the Outrigger implementation and the corresponding 
tests.

The tests assume that the JavaSpace implementation is *required* to 
detect and throw exceptions for expired transactions, and must not issue 
a notify for a write the corresponds to one.

The Outrigger implementation of JavaSpace assumes that it is OK to cache 
a transaction, and not consult its manager every time something is done 
involving it. The result is that actions related to a transaction can go 
on after the transaction has expired.

In this case, it is a matter of continued notify events for writes 
associated with an expired transaction.

I need advice from more River-experienced people on which is right, the 
tests or outrigger, on this issue.

Patricia


On 10/27/2010 3:02 PM, Patricia Shanahan 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
>