[Libpqxx-general] asyncconnection

[Jeroen T. Vermeulen]

On Tue, September 4, 2007 01:35, Arliones Hoeller Jr wrote:

> Hi there,

Hello!


> I'm trying to use a asyncconnection to have my client application notified
> when some tables on my DB change. In order to do it, I created a trigger
> on
> the DB that runs "NOTIFY signal", and I run "LISTEN signal" on my client.

There's no need to run LISTEN.  That's what the trigger class is for. 
More about this below.


> Once I want to run the "listen command" as soon as the connection is
> stabilished, I specialized the asyncconnection::do_completeconnect method
> to
> run the listen command. Is this correct? Is this the correct semantics of
> the asyncconnection::do_completeconnect method (i.e., this method is run
> when the connection is stabilished)?

Afraid not.  The do_completeconnect() function and friends implement the
internal workings of the different connection types.  Don't mess with them
unless you're adding a new class to the connection hierarchy, which is
probably not what you want.

There is no callback for when the connection completes.  Instead, it's the
other way around: if you try to run a command, your connection object will
first make sure that it is fully connected to the backend, waiting for it
if necessary.  That principle holds for all the connection classes: a lazy
connection will not even make its first attempt to connect until you try
to run a command, and any connection will (if safe) reconnect if the
connection was broken or deactivated.  More about this in answer to your
next question.

For your case I'd recommend using a regular connection and creating a
trigger on it.  The async connection type only buys you asynchronicity
while starting up; after that, all connection types are the same.  If you
find that network latency is a noticeable cost for you, and you need
faster startup, you can try using an asyncconnection again.  If you do,
just to make sure, I'd suggest you call activate() on the connection when
you really want to start listening.  That way there can be no
misunderstanding about whether the connection should activate itself just
to enable your trigger.


> Another doubt I have regards what happens if the connection is lost. Does
> libpqxx reconnects to the DB by itself? Does it runs
> asyncconnection::do_completeconnect again when this connection is
> re-stabilished?

Yes, libpqxx automatically re-establishes connections, though any
transaction you're running at that point will of course be aborted.  If
you use LISTEN, the new connection won't know about that and so you'd have
to re-issue the LISTEN command.  If you use libpqxx's triggers instead,
this is done automatically.


Jeroen