[odb-users] strategies for dealing with blocking behaviour (postgresql)

[Boris Kolpackov]

Friedrich Haven <cmusch at gmx.at> writes:

>    my understanding is that ODB offers a blocking API, and uses the
>    blocking API of underlying libraries (e.g. PQExec for postgresql).
> 
>    What is the intended way to deal with situations in which blocking is
>    not acceptable? Are there reasonable alternatives to just wrapping ODB
>    calls in threads?
>    Are there any ideas or plans about offering a non-blocking style of
>    interaction in a future version?
> 
>    My specific scenario is: ODB is used to connect to a postgresql
>    cluster behind a virtual IP. Failover of the cluster can lead to
>    blocking calls which return only after several tens of seconds (after
>    certain TCP timeouts run out), long after the failover successfully
>    happened.

While we are not against supporting non-blocking API in principle,
I am not sure the amount of complexity the inversion of control will
introduce will be justifiable in this case (AFAIR, you are the first
asking for such a feature).

I am also having a hard time imagining how such a support would be
used to solve your case without turning everything into quite a
mess (though, admittedly, I didn't spend much time thinking about
it). How do you see this working? Do you start, say, a load() call
asynchronously, and then, after some timeout, decide that it's no
good, and start another one on the same object? What if the first
call ends up succeeding and they both end up writing to the same
object? Maybe if you could sketch in a bit more detail how you see
this working in your case (including how you would decide to abandon
an in-progress call), it would help come up with a sensible solution.