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