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