i don't have the answers to your questions offhand - will come back to it though. I created some issues so I don't lose track of this stuff:
1. for the CLOSE_BEHAVIOR issue - https://issues.apache.org/jira/browse/TINKERPOP3-764 2. for the EventStrategy/Listener stuff - https://issues.apache.org/jira/browse/TINKERPOP3-765 On Thu, Jul 9, 2015 at 4:12 PM, Matthias Broecheler <[email protected]> wrote: > > > > The listeners were built with EventStrategy in mind. As such, all > > mutations made in a Traversal with this strategy in place, aggregate to > > > How does that work exactly? EventStrategy registers a listener when it is > invoked for a particular traversal which then fires off the queue? > How does EventStrategy remove that listener? Or does the listener then > stick around in that particular thread until eternity (i.e. memory leak)? > > > > > > > On Thu, Jul 9, 2015 at 3:45 PM, Matthias Broecheler <[email protected]> > > wrote: > > > > > Similarly, the default CLOSE_BEHAVIOR implementations seem to only > close > > > the transaction of the current thread that closed the graph. > > > > > > On Thu, Jul 9, 2015 at 12:37 PM Matthias Broecheler <[email protected]> > > > wrote: > > > > > > > Hi guys, > > > > > > > > having a closer look at the implementation, I think the transaction > > > > listener interface is broken. > > > > > > > > The way that this is documented and implemented doesn't seem to > satisfy > > > > any reasonable use case: > > > > A listener is invoked for all transactions that are committed/rolled > > back > > > > in a particular thread. > > > > > > > > Why would a user care about the implementation detail of how many > > threads > > > > a database uses to answer user queries? > > > > Just assume a simple case where the server uses 2 threads. If the > > > > registers a listener she does so for a particular thread (random) and > > > then > > > > all transactions on that thread trigger the listener. How is that > > useful? > > > > > > > > I can see 2 use cases for transaction listeners: > > > > 1) You want to listen for ANY transaction that commits or rolls back > > > > irrespective of which thread its on, i.e. "when any transaction > > > concludes, > > > > do X" > > > > 2) You want to listen for a single transaction committing or rolling > > > back, > > > > i.e. "when this particular transaction concludes, do X". > > > > > > > > The current implementation falls somewhere in between which requires > > the > > > > user to reason about threads. > > > > > > > > What are we actually trying to accomplish with those listeners? > > > > Thanks, > > > > Matthias > > > > > > > > > > > > > >
