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
