> without it, the same programs may have different results when executed on different databases.
It would be nice if we could make it so that TinkerPop-level transactions allowed for more control over the expectations of a traversal. There are many instances where mutation oriented traversals have different results depending on the backend and what it does from a transactional standpoint in relation not only to the mutations but also to how it handles read operations that might follow later in that same traversal. If we could always assure the same result no matter what the backend was, that would be huge. I imagine though that this "tuple-transactions" don't have any magic to them and that building a unified transaction system in TinkerPop will still be "hard". On Wed, May 15, 2019 at 12:34 PM Joshua Shinavier <j...@fortytwo.net> wrote: > Tough question, since I have not used Akka or the actor model, but here are > some first thoughts. From what I am reading, the trick would be to > implement the transaction log as a CRDT > <https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type>. > Operation-based CRDTs -- which propagate individual mutations as opposed to > local state -- appear to be preferable if mutations are commutative. So are > they commutative? In the "imperative" scenario I described to Stephen, no. > In the "functional" scenario, yes, they have to be. Suppose you insert a > vertex and also delete that vertex. The eventually consistent result of the > transaction must be a no-op; if the vertex already exists, leave it alone. > If it does not exist, do not create it. However, it does not matter in what > order you perform the insert and delete -- once all operations are > accounted for, you arrive at the correct state. > > Just from what I glean from Wikipedia, there appear to be a handful of > well-known strategies for operation-based and state-based CRDTs. I do not > know how hard it would be to support multiple strategies in the same VM, > but in the Akka world, that seems to be the way in which you would choose > your operational semantics. > > Josh > > > > > On Wed, May 15, 2019 at 8:00 AM Marko Rodriguez <okramma...@gmail.com> > wrote: > > > Wow. I totally understood what you wrote. > > > > Question: What is the TransactionLog in a distributed environment? > > e.g. Akka-driven traversers spawned from the same > > query migrating around the cluster mutating stuff. > > > > Thanks for the lesson, > > Marko. > > > > http://rredux.com <http://rredux.com/> > > > > > > > > > > > On May 15, 2019, at 8:58 AM, Joshua Shinavier <j...@fortytwo.net> > wrote: > > > > > > Hi Stephen, > > > > > > More the latter. TinkerPop transactions would be layered on top of the > > > native transactions of the database (if any), which gives the VM more > > > control over the operational semantics of a computation in between > > database > > > commits. For example, in many scenarios it would be desirable not to > > mutate > > > the graph at all until a traversal has completed, so that the result > does > > > not depend on the order of evaluation. Consider a traversal which adds > or > > > deletes elements as it goes. In some cases, you want writes and reads > to > > > build on each other, so that what you wrote in one step is accessible > for > > > reading in the next step. This is a very imperative style of traversal > > for > > > which you need to understand how the VM builds a query plan in order to > > > predict the result. In many other cases, you might prefer a more > > functional > > > approach, for which you can forget about the query plan. Without > VM-level > > > transactions, you don't have this choice; you are at the mercy of the > > > underlying database. The extra level of control will be useful for > > > concurrency and parallelism, as well -- without it, the same programs > may > > > have different results when executed on different databases. > > > > > > Josh > > > > > > > > > > > > > > > On Wed, May 15, 2019 at 6:47 AM Stephen Mallette <spmalle...@gmail.com > > > > > wrote: > > > > > >> Hi Josh, interesting... we have graphs with everything from no > > transactions > > >> like TinkerGraph to more acid transactional systems and everything in > > >> between - will transaction support as you describe it cover all the > > >> different transactional semantics of the underlying graphs which we > > might > > >> encounter? or is this an approach that helps unify those different > > >> transactional semantics under TinkerPop's definition of a transaction? > > >> > > >> On Wed, May 15, 2019 at 9:23 AM Joshua Shinavier <j...@fortytwo.net> > > >> wrote: > > >> [...] > > > > >
