Reactive Stream Questions

[Douglas Surber]

I understand the confusion.

When describing ADBA (the MAIN branch) I try to be clear that there are (at least) two timelines to consider: the user thread timeline which runs at full CPU speed and never blocks and the async timeline which runs in the background as Operations are carried out. (There’s actually a third timeline, the execution of dependents of the CompletionStages.)

The RS proposal does not change this. The user thread creates and submits Operations without ever blocking. The Operations are wired together with Publishers rather than CompletionStages.

In writing code using ADBA I don’t think about the two timelines. I think about constructing and composing Operations. The Operations are wired together with the appropriate dependencies. If the Operation graph is correct then the result will be correct, whenever it is completed. The timing of the async execution is abstracted away.

In a more pure reactive stream API like Ben references, the construction and composition of the computation creates a stream graph. The computation proceeds when the environment demands a result from the end of that graph.

The difference between the MAIN and RS branches of ADBA is the glue used to wire Operations together. MAIN wires them together with CompletionStages. RS wires them together with Publishers.

Douglas

> On Aug 1, 2018, at 10:46 AM, Oleh Dokuka <shadowgun at i.ua> wrote:
> 
> I guess for all of us ( I mean who got used to separate reactive and imperative ) try-with-resource is an imperative synchronous operation, so once we saw that try-with-resource in the combination of execution potential async operation, we immediately saw the problematic point. However, as you mentioned earlier, 
> 
>> execution of Session.close() does not stop the Session from carrying out work or release any resources.
> 
> which means that even if the session is getting closed, the execution of the flatten inner stream will be successful which is totally fine. From the first glance it is very confusing but in case of such behavior, it is fine.
> 
> so returning back to the initial question the following style will be preferable:
> 
>>    ds.flatMap( session -> {
>>      session.<Employee>rowPublisherOperation(sql) . . .
>>    }
> 
> It is preferable because it will not cause so many question ( as we did during that topic discussion ) if the internal implementation will be hidden and the user just get the session for operate on it.
> 
> 01.08.2018 20:31, Douglas Surber <douglas.surber at oracle.com>
>> 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.
>>>> 
>>> 
> 
> 
> -- реклама -----------------------------------------------------------
> Самый летний отель юга Украины, бронируй отдых со скидкой 
> 20% при бронировании от 3 ночей -> https://urldefense.proofpoint.com/v2/url?u=https-3A__is.gd_S2KM7u&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=DFcFtomvCycx6XeC1vpTp5TdBqlgkiljGpb5LljiXB4&m=dZoyn4tthaN4OEngv14DXIg9QKfxDmHNTd9IL80Drno&s=l7A8KmG04KNN9zEmdpPI06djNvBMnH3wUmv3WQLTlbg&e=