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

[Friedrich Haven]

Hi,

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


> 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).

Actually I would have been surprised to learn about such plans, given
the amount of questions this would raise. But still I needed to ask :)


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.


Of course this is an elaborate and brittle solution, we are not
super-happy about it, but that is the best we came up with...

looking forward to your thoughts
christian