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 <[email protected]> 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 <[email protected]> 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 > > >
