Re: Beating Oracle

> The reason I'm so unenthused about this is that I think it'd be quite
> difficult to do transparently at the database level.  (1) How can you
> know where communication was lost, from the other end's point of view?

Actually, if we're talking about transient TCP failures here (ie. one in X 
connections dies halfway through a transaction), then [1]libpqxx does have 
the logic built-in for semi-transparent connection recovery.

I'm not sure this is quite what is needed here, but what it does right now 
is reset the backend connection (PQreset() I think the function was), 
forget about the current attempt at performing the transaction, and re-
running the client code that makes up the transaction.  So we're not 
talking about a simple replay of old SQL, but a simple framework for 
writing restartable code that "plugs into" a connection.  Look for the 
Transactor base class.

If PQreset() is not sufficient, I see no fundamental problem in doing an 
entire new connect instead.

The one underlying assumption of course is that the client side will know 
if the connection was lost.  If TCP and libpq guarantee that much, then the 
libpqxx mechanism should solve the problem perfectly.  All we need now is 
two-phase commit.  :-)


> (eg, client has no idea whether database completed the last request
> sent.)  I think you'd wind up reimplementing TCP, or something much
> like it, just to deal with that aspect of the problem.  (2) How can you
> even be sure that you're reconnecting to the same other-end session?
> Opportunities for security holes seem rampant.  (3) Should the database
> hold sessions open indefinitely, waiting to see if the client can be
> recontacted?  Won't take too long until your session limit is entirely
> filled by dead connections.

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.


Jeroen

[1] http://members.ams.chello.nl/j.vermeulen31/proj-libpqxx.html