river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: [jira] Created: (RIVER-393) Distributed Java Space
Date Sat, 05 Mar 2011 09:40:46 GMT
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.



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