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