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, > > >
