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