Bug fixing - JavaSpace and Transaction issue

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

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

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
>

Re: Bug fixing - JavaSpace and Transaction issue

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

I've since found and fixed the root cause of this issue. There was a bug 
in TxnManagerImpl.java that stopped it from aborting a transaction when 
it is canceled while active. Once I fixed that, all the failing 
javaspace tests started working.

Patricia



Gregg Wonderly wrote:
> 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 <pa...@acm.org> 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
> 

Re: Bug fixing - JavaSpace and Transaction issue

[Gregg Wonderly <gr...@wonderly.org>]

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 <pa...@acm.org> 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