I have only seen examples of opening and closing the connections inside of
filter_sender or filter_end. Is it possible to open a connection in
mimedefang when it starts up and close it on exit. I would like to insert
some information in a table from filter_relay, filter_sender and
On Thu, Dec 14, 2006 at 07:13:56AM -0500, David F. Skoll wrote:
You can do anything you want, as long as you open the connection in
filter_initialize(), and close it in filter_cleanup()
That's one strategy. I prefer to lazily open and close the connection.
That is, have a wrapper function
Jan-Pieter Cornet wrote:
so... something like DBI-connect_cached
Exactly! :-) I never even knew that existed. Thanks!
Regards,
David.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may
Mack wrote:
Be very careful with connect_cached though, as I have noticed that you get a
SQL server has gone away when you try to use the connection, even though the
connect cached still thinks it is open and pings (after maybe 6-12hrs
inactivity - so shouldn't be a prob on a busy site
!)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
F. Skoll
Sent: 14 December 2006 14:46
To: mimedefang@lists.roaringpenguin.com
Subject: Re: [Mimedefang] Mysql connections
Jan-Pieter Cornet wrote:
so... something like DBI-connect_cached
Exactly! :-) I never even
Mack [EMAIL PROTECTED] 14/12/2006 16:36
Be very careful with connect_cached though, as I have noticed that you get a
SQL server has gone away when you try to use the connection, even though the
connect cached still thinks it is open and pings (after maybe 6-12hrs
inactivity - so shouldn't
If you put a dbh-prepare statement immediately before each execute(), it
should work...bearing in mind that I haven't been able to test this.
Only advantage gained here is the persistant connection, as the prep
statements (or prep_cached) seem to have their own large overheads..
My guess is
If you put a dbh-prepare statement immediately before each execute(), it
should work...bearing in mind that I
haven't been able to test this.
Only advantage gained here is the persistant connection, as the prep
statements (or prep_cached) seem to have their own large overheads..
So write a
So write a new connect_cached() which also re-prepares the statements on a
reconnect...
Too lazy ! Lol
Alternatively, have filter_tick defined, and make it run a query on the
database, then configure the
multiplexor to use the tick function, which will stop the connection
timeout.
Nice idea
Paul Murphy wrote:
Alternatively, have filter_tick defined, and make it run a query on
the database, then configure the multiplexor to use the tick
function, which will stop the connection timeout.
That won't work, because you have no idea which slave will run the tick.
All the ticks might
I have a simple question and maybe someone has an example for me and others
on the list. I have searched the list and looked at the examples. I have
only seen examples of opening and closing the connections inside of
filter_sender or filter_end. Is it possible to open a connection in
11 matches
Mail list logo