JBossDeveloper

Looks like this is my fault.  Thanks Steve for pointing out the bugs in our translator and my apologies to Sanjeev for chasing down my bugs  

> The primary issue here with your initial modification is that this is a reusable execution.  Its state is not being fully reset and the dataavailable event is running only a single time.  So if on reuse after the dataavailable event has already fired we are in the waiting state from a previous execution cycle, then you'll hang as no more dataavailable events are running.

I had originally thought that reusable executions were an integral part of continuous executions but now I understand that they're more of an optional optimization particularly since an execution instance can be reused in a different node within the plan.  It does bring up a question though:  Do you have a recommended approach for an execution to maintain state between executions?  One way I've done it in another translator is to maintain a map of execution id -> state within the execution factory and use CommandContext listener to clean up state when the command is completed.  I think this approach works but it's a bit awkward.

> Do you have a recommended approach for an execution to maintain state between executions?

This seems simple, but is somewhat complicated from an engine perspective.  The execution even when reusable looks more to us like a prepared statement (although we don't cache based upon the command, just the translator/source).  So between uses, even for the same node, it's entirely possible for reference values to have changed - for example when the execution is part of a correlated subquery.  Then there's the other issues that have been brought up before about multiple/parallel executions from the same node (such as with dependent joins), dynamic sql, etc.

I think what you are looking for out of reuse is sufficient limited that it makes intuitive sense to have state associated with the execution.  But it may be better to think of associating the state with command.  Right now we only expose session variables on the command context, but we could just as easily allow for command scoped variables.  Then there wouldn't be a cleanup issue.

> This seems simple, but is somewhat complicated from an engine perspective.

I'm very sympathetic to this. 

> I think what you are looking for out of reuse is sufficient limited that it makes intuitive sense to have state associated with the execution.  But it may be better to think of associating the state with command.  Right now we only expose session variables on the command context, but we could just as easily allow for command scoped variables.  Then there wouldn't be a cleanup issue

I like the general approach though I'm not clear on exactly what you're suggesting.  I'm thinking something like hash map associated with the command.  For execution-specific state, I think we could use execution id as the key.