Persistent DB connections and other persistent resources (was Re: [Mimedefang] SpamAssassin and SQL user preferences)
Aaron Paetznick
aaronp at critd.com
Mon Sep 9 10:35:01 EDT 2002
That sounds like a very reasonable approach. I will give it a try and
post the results to the list.
Thanks!
--Aaron
David F. Skoll wrote:
> On Sun, 8 Sep 2002, Aaron Paetznick wrote:
>
>
>>David, what
>>if we provided native, persistant facilities from the multiplexor? That
>>would be far better, IMHO.
>
>
> This is not required. If you want a persistent database connection, there
> are two ways to do it:
>
> 1) Open it inside the filter, outside any subroutine definition. Keep the
> connection in a global variable.
>
> 2) Keep a global variable, something like this, in filter_begin:
>
> sub filter_begin {
> unless defined ($DatabaseConnection) {
> $DatabaseConnection = my_db_connect_func(whatever);
> }
> # ...
> }
>
> The global variable (and the database connection) will persist until the
> slave is killed, after it has processed its limit of messages.
>
> There is no hook for cleaning up, but this should not be necessary because
> the Perl process terminates anyway. If you absolutely postively need
> a cleanup, trap SIGINT, do you cleanup in the signal handler and exit.
>
>
>>SpamAssassin does have built-in hooks for database preferences, but
>>providing this functionality from within MIMEDefang would be far more
>>elegant, also IMHO.
>
>
> And it's how CanIt works. I do not use persistent database connections,
> because so far the overhead has been acceptable. I might change that
> later on.
>
> --
> David.
>
> _______________________________________________
> MIMEDefang mailing list
> MIMEDefang at lists.roaringpenguin.com
> http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
More information about the MIMEDefang
mailing list