river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: [jira] Created: (RIVER-393) Distributed Java Space
Date Sat, 05 Mar 2011 09:55:16 GMT
We've talked a lot about transactions and "persisted safely" but as yet I've
seen no discussion of ordering (from the spec):

"Operations on a space are unordered. The only view of operation order can
be a thread's view of the order of the operations it performs. A view of
inter-thread order can be imposed only by cooperating threads that use an
application-specific protocol to prevent two or more operations being in
progress at a single time on a single JavaSpaces service. Such means are
outside the purview of this specification.
For example, given two threads *T* and *U*, if *T* performs a write operation
and *U* performs a read with a template that would match the written entry,
the read may not find the written entry even if the write returns before
the read. Only if *T* and *U* cooperate to ensure that the write returns
before the read commences would the read be ensured the opportunity to find
the entry written by *T*(although it still might not do so because of an
intervening take from a third entity)."

In particular note that last sentence and the implications it has for
completion of operations.

Note also the the persistent property amounts to when an operation completes
(or indeed a transaction) successfully, the operation(s) are now
"remembered". "Remembered" being persisted with whatever guarantee a space
provides. Traditionally that's transient (temporary in-memory) and
persistent (recovered across space restarts, spec is silent on the quality
of storage and its redundancy).

If you ask me then, what needs considering is:

(1) If we wish to relax the operation ordering constraints further.
(2) Which if any of the operations we do not wish to support (*IfExists can
be particularly tough to implement efficiently).
(3) What our persistence guarantees will be.

Transactions don't actually matter in any of the above as they are just
another form of operation boundary. Transactions are "durable":

"The results of a transaction should be as persistent as the entity on which
the transaction commits."

But that's ultimately defined by (3) above, rather than transactions
themselves.

On 5 March 2011 09:40, Tom Hobbs <tvhobbs@googlemail.com> wrote:

> I have no preconceived idea about what "persisted safely" means.
> Assuming some implementation like an RS orchestration layer on top of
> a series of normal Java Spaces, part of the configuration might be
> "safely persisted means that the entry exists in at least x available
> underlying spaces".
>
> You're right about transactions being closely related and should be
> considered along with everything else.  I'm (maybe more) keen to talk
> about other kind of features like;
>
> - should those transactions be controlled by the client using the RS
> or should the RS use them transparently
> - the "optimistic writing" etc that I mentioned in the space
>
> Without understanding more about how the thing will/might be used I'm
> less inclined to start thinking about how to build it.
>
> But like I said in the Jira, these things are what I naively think are
> important - that doesn't mean that I didn't miss some other big stuff.
>
> Cheers,
>
> Tom
>
>
> On Fri, Mar 4, 2011 at 1:47 PM, Patricia Shanahan <pats@acm.org> wrote:
> > On 3/4/2011 3:47 AM, Tom Hobbs (JIRA) wrote:
> >
> >>  - Block the write method call until the RS is happy the entry is
> >> persisted safely
> >
> > Could you define what you mean by "persisted safely"? Do you count
> getting
> > it to non-volatile storage, or does it need to be stored on multiple
> > servers? If the transaction is in non-volatile storage but that storage
> is
> > attached to a dead server, the entry exists only in a very theoretical
> > sense, and attempts to read or take it would fail.
> >
> > I feel that distributed transactions are sufficiently closely related
> that
> > they should be discussed in the same Jira.
> >
> > Patricia
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message