Reactive Stream Questions

[Douglas Surber]

I don’t understand what you mean by “rowCountOperation() needed to be lazily calculated”.

If a parameter to the rowCountOperation depends on the result of a previous SQL operation the value of that parameter would be set to the Publisher of that result. If execution is conditional, the rowCountOperation could be a member of a conditional OperationGroup. 

The point is the user thread runs at full CPU speed submitting the Operations that need to be executed up to and including the close. Additional member Operations can be added to an OperationGroup after the OperationGroup and a subsequent closeOperation are submitted. So additional Operations can be submitted by the asynchronous processing of previously submitted Operations. In the overwhelming majority of cases the user thread can submit a closeOperation using try with resources.

And in the very rare case where that won’t work, then don’t use try with resources.

Douglas

> On Aug 1, 2018, at 10:21 AM, Ben Hale <bhale at pivotal.io> wrote:
> 
> The difference is that the close is submitted synchronously with submission of the operation.  If that rowCountOperation() needed to be lazily calculated, the close comes too early.  In the RS world, all of the closures ensure that the close call not only isn't submitted to the queue, but the call isn't even made until it's ready to execute.
> 
> 
> -Ben
> 
> 
>> On Aug 1, 2018, at 11:24, Douglas Surber <douglas.surber at oracle.com> wrote:
>> 
>> Session.close submits a closeOperation. Execution of this operation is async. Try with resources works exactly as desired. The reactive stream alternative is in no way different is this regard from MAIN.
>> 
>>  try (Session s = ds.getSession()) {
>>    s.rowCountOperation(sql).submit();
>>  }
>> 
>> In this example the user thread submits three Operations without blocking, attachOperation, rowCountOperation, closeOperation. The closeOperation is likely submitted long before the attachOperation is executed, but that is just fine. CloseOperation is every bit as asynchronous as the rowCountOperation.
>> 
>>> On Aug 1, 2018, at 7:29 AM, Ben Hale <bhale at pivotal.io> wrote:
>>> 
>>> try/catch, because it happens within the execution flow rather than async, is problematic in an RS environment.  Instead, you need to directly execute a close at the appropriate point in the async execution.
>> 
>