river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: [jira] Created: (RIVER-393) Distributed Java Space
Date Sat, 05 Mar 2011 12:50:52 GMT
Whether or not we need to change the meaning of the ordering 
specification, we certainly need to make it more formal.

One key issue is whether the specification implies a global total order 
of all operations, such as one would naturally get if they all operate 
on a single data structure. Sun historically had a tendency to build in 
that assumption.


On 3/5/2011 1:55 AM, Dan Creswell wrote:
> 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

View raw message