Re: Beating Oracle

<jtv(at)xs4all(dot)nl> writes:
> Basically, libpqxx solves these problems at the client side--it doesn't try
> to reconnect to an older session, but simply leaves the old session to
> wither and die while it starts up a new one to perform the same task. This
> takes very little in the way of state-keeping on either side.

This scares the hell out of me. How do you know whether the old session
committed your transaction, but the connection died just before it could
tell you so? libpqxx is the very LAST place in the chain that is
qualified to undertake the task of error recovery.

There are cases where the best way to design the client code is to make
it automatically rollback and then retry whole transactions. (In
particular, if you use SERIALIZABLE transaction mode then this is more
or less essential to cope with concurrency violations.) If you've got a
client that's built that way, then it's a pretty simple matter to extend
the client to do the same sort of retry for connection-level failures,
too. But I'd still be worried about the prospect of double execution of
a transaction, if the link was lost just after you issued a COMMIT and
just before the backend could tell you it had committed. So you'd also
need to add code to verify you hadn't already executed the transaction.

In any case, I do not think that libpq or libpqxx can or should try to
hide this problem from the client.

regards, tom lane