Transaction listener

[Matthias Broecheler <me...@matthiasb.com>]

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

Re: Transaction listener

[Stephen Mallette <sp...@gmail.com>]

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 <me...@matthiasb.com>
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 <me...@matthiasb.com>
> > 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 <me...@matthiasb.com>
> > > 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
> > > >
> > > >
> > >
> >
>

Re: Transaction listener

[Matthias Broecheler <me...@matthiasb.com>]

>
> 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 <me...@matthiasb.com>
> 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 <me...@matthiasb.com>
> > 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
> > >
> > >
> >
>

Re: Transaction listener

[Stephen Mallette <sp...@gmail.com>]

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 <me...@matthiasb.com>
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 <me...@matthiasb.com>
> 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
> >
> >
>

Re: Transaction listener

[Matthias Broecheler <me...@matthiasb.com>]

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 <me...@matthiasb.com>
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
>
>