The listeners were built with EventStrategy in mind. As such, all mutations made in a Traversal with this strategy in place, aggregate to a queue. The queue of "events" are not fired until there is a commit()/rollback(). In this way, the "time to fire" is tied to the current thread that your executing the traversal in. For this case, you don't want to know when ANY call to commit (your first use case) is performed or else your events would fire at the wrong time. I guess this fits more into your second use case - though the second use case, just sounds like ThreadLocal stuff to me as graphs that support transactions tend to support that approach. TinkerPop doesn't have a first-class Transaction object to work with that you could bind a listener to.
And, you're right about CLOSE_BEHAVIOR - I'd long forgotten that issue unfortunately. Perhaps we can better delegate that function to implementers somehow to get a cleaner shutdown?? 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 > > > > >
