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 <p...@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 >
