Reactive Stream Questions

[Douglas Surber]

This does not require blocking on the Operation. No user thread call blocks ever. Any action that has the potential to block, for example talks to the database, is modeled as an Operation. The user thread creates, configures, and submits these Operations. Creating, configuring, and submitting never blocks. Attaching a Session to the database potentially blocks and so is modeled as an attachOperation. Disconnecting a Session from the database potentially blocks and so is modeled as a closeOperation. 

The example below creates and submits three Operations: attachOperation, rowPublisherOperation, closeOperation. Creating and submitting them does not block. The Operations are executed in the background. This is no different from the MAIN branch.

Douglas

> On Jul 31, 2018, at 6:04 PM, James Roper <james at lightbend.com> wrote:
> 
> Q3: Assume DataSource extends Flow.Publisher<Session>.
> 
>     ds.flatMap( s -> {
>       try(Session session = s.attach()) {
>         session.<Employee>rowPublisherOperation(sql) . . . 
>       }
>     });
> 
> Correct me if I'm wrong, but this option would require that you block on the result of the operation, otherwise the session will be closed before its finished being used. That would defeat the purpose of having an asynchronous database driver.
>