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
