The listener on Transaction is only meant to provide notification when commit() is called. That's about it. The meaning of commit() in terms of what that event means is dependent on whether it is called via AbstractThreadedTransaction or AbstractThreadLocalTransaction. If the provider has extended their Transaction implementation via AbstractThreadedTransaction then the event raised from commit() will essentially be global across all threads that interact with that listener. If the provider has extended their Transaction implementation via AbstractThreadLocalTransaction then the event raised from commit() will apply to the current thread only which is typically what is desired from EventStrategy where you execute:
g.V().addV() g.tx().commit() and then expect to signal EventStrategy to notify of all the change that occurred on that thread of execution. The intent is not for "global" mutation listening or general logging if i understand those concepts as you are using them properly. It is meant to track what happens local to changes that occur within a single transaction (which typically means a thread as most graphs are bound to ThreadLocal transactions). On Mon, Nov 2, 2015 at 2:08 PM, David Robinson <[email protected]> wrote: > Hi Stephen, > > I am still trying to understand the thought behind the existing TP pieces > and how they > fit into the topic of graph mutation listening in general. > > Looking at AbstractThreadedTransaction, there is the addTransactionListener > method which > accepts a Consumer object. Can you help me understand when an implementer > would > use something like this ? Is this the intended mechanism for global > mutation listening > or "logging" in the TP design ? > > Looking at the EventStrategy class, there is an addListener method which > wants a > MutationListener, but with several caveats about global mutations or > mutations outside > of a Traversal so I am not sure how this fits with the > AbstractThreadedTransaction listener > pieces. > > Are there also other graph mutation listener pieces I've missed ? > > > > On Mon, Nov 2, 2015 at 1:27 PM, Stephen Mallette <[email protected]> > wrote: > > > David - the event methods aren't new...the decomposition of the > > AbstractTransaction class into AbstractThreadedTransaction and > > AbstractThreadLocalTransaction are new for 3.1.0. Isn't that what you > > mean? > > > > Either way, that change doesn't really address Matthias' points. It does > > however provide better flexibility to graph providers as they can choose > > the appropriate transaction model for their implementations. Before this > > change, AbstractTransaction didn't give an option to those with "threaded > > transactional" capabilities. That was a bit of a first step to solving > the > > problem, but I've not thought about it much since then and the issues > > remain open as to the "semantics of close" (which you'll see plenty of > > discussion on in JIRA and this list). > > > > You've done work in this area (eventing) and are familiar with it > > apparently. If you can make EventStrategy work nicely and address > concerns > > you share with matthias, then please start the discussion and build > toward > > a pull request. If you had a good idea it might untangle our needs with > > "close semantics" which are still rather fishy. > > > > > > > > > > > > > > On Mon, Nov 2, 2015 at 11:40 AM, David Robinson <[email protected]> > > wrote: > > > > > There was only a limited amount of design discussion that I am able to > > find > > > around the relatively new listener methods added to > > > AbstractThreadedTransaction/AbstractTransaction classes by > > TINKERPOP3-765 - > > > that was also listed as "breaking", which, indeed, it is. > > > > > > Can someone (Stephen?) post more information about the thoughts behind > > this > > > design ? Matthias expressed unaddressed concerns: > > > *http://tinyurl.com/omuz49e > > > <http://tinyurl.com/omuz49e> * > > > > > > The Jira says very little about "why" this particular design was > > selected. > > > > > > I have similar concerns as Matthias. The design feels overly > complicated > > > and actually backwards from the way I was thinking about it. None of > > these > > > things were required to get events out of Titan for the draft Kafka > > > provider - so what is the value ? > > > > > > I believe the design expectation is that an Implementer, when creating > a > > > transaction object, will register an "EventListener" with the > > transaction, > > > and then when the transaction completes, the appropriate EventListener > > > methods will be called ? Even if that is correct, why so many methods > on > > > Transaction ? > > > > > > > > > Thank you, > > > > > >
