Blitz has users across both modes (persistent and transient) so I wouldn't say there's a clear divide.
Where a tuplespace is not a system of record and contents can be re-generated or are time sensitive (trading data) and will be updated shortly, transient tends to win. Those treating the tuplespace as a system of record (data storage scenarios) or needing persistence of a workflow (e.g. for complex calculations) etc use persistent mode. Note that in both modes, transactions are used as much as they aren't, because it's really about a level of atomicity as much as or instead of durability. On 22 February 2013 09:16, <[email protected]> wrote: > Thanks Dan, > > how is it used in practice? Do transient deployments prevail? > > --Joerg > > -----Original Message----- > From: "Dan Creswell" <[email protected]> > Sent: Thursday, February 21, 2013 6:50pm > To: [email protected] > Subject: Re: transient tuple space > > A bit of history: > > Jini (now River of course) went to great lengths to separate > implementation details from service abstractions. That is the "how" > was not nearly as important as the "what". "Do one thing well" was a > phrase oft-quoted in respect of services. > > And so to JavaSpaces: > > The spec basically says that if the JavaSpace is a transient > implementation, it will forget its contents at the time of exit (crash > or normal). Persistent is the opposite, contents are remembered across > exits (crash or normal subject to transactional constraints of > course). > > Given the above, a transient space could actually make use of disk > perhaps as an overflow for memory. Thus (b), below is to my mind the > "correct" interpretation of the spec. > > On 21 February 2013 20:28, <[email protected]> wrote: >> All, >> >> what is a transient mode/tuple space by definition. To me the documentation >> is not quite clear whether it is >> >> a. an in memory tuple space that does not use slow disk space >> >> b. a tuple space that may or may not use disk space for storage but that is >> in any case not preserved after a restart >> >> --Joerg >> >> > >
