Dear Jeroen, On 2005.12.21. 15:49, Jeroen T. Vermeulen wrote:
Well it's mostly a natural effect of the way connections work: they activate when you need them. Actually the current CVS version does the activate() automatically at construction time, so any errors should be immediate, but that's a recent change.
Understood. Tried activate and it does work the way I expected! Thanks!
Right. With the connections' built-in reconnection mechanism you never even need to notice that it happens. For best effect, try transactors which will also re-run the entire failed transaction up to some specified maximum number of times.
Sir, yes, Sir! ^^
That will not happen for timeouts, however, only for things like misconfigured firewalls, servers that aren't running, password changes, and so on.
forgot intentionally ("mis")configured servers. ;) It's a maintenance thing for us. Either that, or we should be able to remotely tell the process to hangup all pqxx activity until resume is allowed. Making it unable to connect makes it understand the situation.
What you could do is write your own notice processor that is more careful about issuing messages than the builtin one. Strange how little attention computer science has generally given to this sort of issue.
Right now thinking on something like that... I think (not really sure what you meant :) )
Tread carefully here: if you issue your LISTEN in a transaction (or nontransaction) of its own, then be aware that your connection may be implicitly restored at some point anyway and so it may actually disappear without your knowledge. Using the trigger mechanism provided by libpqxx takes care of that. If you really want to do it yourself, at least inhibit automatic reactivation while the LISTEN remains active.
I chose not to use the trigger mechanism because I fear mid-transaction notifications. I certainly do not want to do that. Just issue LISTENs when connected, then doing my work, and check for incoming notifs (get_notifs()) when it's comfortable.
:-) Well, the whole point of having exceptions is that you're not expected to fill your code with handlers. Put try blocks in a few key places, generally as close to user-level commands as possible, plus some other places where your code knows how to recover or retry. The libpqxx
That's the problem: my code is full of such places where I at least know how to, at most have to recover (or finish something) or retry.
Thank you and merry xmas, -- G. _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
