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

[Boris Kolpackov]

Friedrich Haven <cmusch at gmx.at> writes:

> We have settled now on a way to deal with the situation, which I want to
> outline below for reference of future readers.

Thanks, appreciated.


> What we actually want to achieve is to have a blocking API, but
> returning from a blocking call (unsuccessfully) if a database failover
> happens (so a database reconnect can be triggered).
> 
> We now achieve this with the help of two threads (in addition to the
> main thread):
> 
> - a "worker thread" which interacts with the database, and calls
>   blocking ODB functions. The main thread dispatches every single DB
>   operation into this worker thread, and waits on a condition variable
>   until the work has been done or a failover is detected.
> 
> - a "monitoring thread" which checks the health / identity of the
>   database. In case a failover is detected, this monitoring thread
>   also wakes the main thread via the CV.
> 
> If a failover is detected, the still blocking worker thread is put
> into a "zombie state" and replaced with a new thread, ready to
> establish a new connection. In the end, the zombie thread will finish
> and be cleaned up.

Hm, I believe in case of PG, given a connection handle (which you can
obtain from the odb::pgsql::connection object) you can get hold of the
underlying socket file descriptor (fd).

Based on that, I wonder if you could get way with just the monitoring
thread by having it close the underlying fd if it detects a failover.
I believe (but haven't tested myself), in this case the blocked main
thread will by unblocked with the connection_lost exception.

The ODB connection_factory interface should be flexible enough to
allow you do arrange for this (i.e., "register" an active connection
with the monitoring thread) without having any special calls in the
main thread.

If you decide to give it a try, I would appreciate a note on how it
panned out.