[jira] Created: (RIVER-188) Spaces spec does not resolve conflict between leasing and transaction specs

["Dan Creswell (JIRA)" <ji...@apache.org>]

Spaces spec does not resolve conflict between leasing and transaction specs
---------------------------------------------------------------------------

                 Key: RIVER-188
                 URL: https://issues.apache.org/jira/browse/RIVER-188
             Project: River
          Issue Type: Bug
          Components: net_jini_space
    Affects Versions: jtsk_1.1
            Reporter: Dan Creswell
            Priority: Trivial


http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4945720

The spaces specification does not resolve the conflict between the
leasing spec's requirement that things go away after their leases
expire[*], and the transactions specification requirement that 2 phase
locking is required.

For example, assume two applications, A and B, that communicate using
the following protocol. A writes a the unique entry R into the space
with a finite lease. B takes R under the transaction T, processes R,
and writes the entry S under T, and then commits T. It is ok if R does
not get acted on, but A needs to be able to tell if R's lease expired
before B was able to take R. To accomplish this A starts a
readIfExists using A as a template and a timeout of Long.MAX_VALUE
short after R's lease is set to expire (A might have to take other
steps after this to see if R had be lost, e.g. try to read/take S).

Assume this timeline :

     B takes R under T
     R's lease expires
     A calls readIfExists(R, null, Long.MAX_VALUE)
     B writes S under T
     B commits T

The following questions arise :

   A's readIfExists call must return null, 
   but when does it return?

   Does B's commit succeed

If A's readIfExists call returns immediately and B's commit succeeds then
we have violated two phase locking since the lock held by T on R was
dropped before the T was resolved. This would cause a problem if 
A now looked for S assuming that its query would have blocked
until S was committed to the space.[BTW, this is Outrigger will
do (most?) of the time]

If A's readIfExists call blocks until after T is committed we have
violated the leasing spec because a resources who's lease has expired
is still visible (though if A knew this was the space's behavior
it could safely look for S with a 0 timeout query).

If A's readIfExists call returns immediately and B's commit fails (or
even B's write of S) we actually honor both specs, but this
(empirically) is non-obvious (so if it is the right behavior should be
called out in the spaces specification) and may not be the behavior we
want (this would also satisfy A if B getting a failure on the commit
attempt meant that R had not be processed (say all of the side effects
had been role back)).

[*] It has be argued in the past that lease holders are not obligated
to drop a resource promptly (or at all) when a resource's lease
expires. (it could be argued that JS.2.3 does make this guarantee
in the case of entries in a space).
The spaces specification does not resolve the conflict between the
leasing spec's requirement that things go away after their leases
expire[*], and the transactions specification requirement that 2 phase
locking is required.

For example, assume two applications, A and B, that communicate using
the following protocol. A writes a the unique entry R into the space
with a finite lease. B takes R under the transaction T, processes R,
and writes the entry S under T, and then commits T. It is ok if R does
not get acted on, but A needs to be able to tell if R's lease expired
before B was able to take R. To accomplish this A starts a
readIfExists using A as a template and a timeout of Long.MAX_VALUE
short after R's lease is set to expire (A might have to take other
steps after this to see if R had be lost, e.g. try to read/take S).

Assume this timeline :

     B takes R under T
     R's lease expires
     A calls readIfExists(R, null, Long.MAX_VALUE)
     B writes S under T
     B commits T

The following questions arise :

   A's readIfExists call must return null, 
   but when does it return?

   Does B's commit succeed

If A's readIfExists call returns immediately and B's commit succeeds then
we have violated two phase locking since the lock held by T on R was
dropped before the T was resolved. This would cause a problem if 
A now looked for S assuming that its query would have blocked
until S was committed to the space.[BTW, this is Outrigger will
do (most?) of the time]

If A's readIfExists call blocks until after T is committed we have
violated the leasing spec because a resources who's lease has expired
is still visible (though if A knew this was the space's behavior
it could safely look for S with a 0 timeout query).

If A's readIfExists call returns immediately and B's commit fails (or
even B's write of S) we actually honor both specs, but this
(empirically) is non-obvious (so if it is the right behavior should be
called out in the spaces specification) and may not be the behavior we
want (this would also satisfy A if B getting a failure on the commit
attempt meant that R had not be processed (say all of the side effects
had been role back)).

[*] It has be argued in the past that lease holders are not obligated
to drop a resource promptly (or at all) when a resource's lease
expires. (it could be argued that JS.2.3 does make this guarantee
in the case of entries in a space).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.