[Mapserver-dev] FastCGI Implementation / connection pooling

[Sean Gillies]

On Sep 23, 2004, at 8:59 AM, Frank Warmerdam wrote:

> Folks,
>
> Refractions and I are not committed to proceeding on the FastCGI
> implementation.  The only comment I had was from Sean who was 
> interested
> in being able to capture the "stdout" output of various functions such 
> as
> the capabilities document generation.  It seems to do what Sean wants 
> well
> would require altering lots of calls to pass in some sort of 
> file/function/buffer
> handle to redirect the data to.  I don't want to do such an intrusive 
> change,
> but I think that my work should make it somewhat easier for Sean 
> if/when
> he wants to proceed with his more comprehensive change.
>
> So, be warned, I will start "virtualizing" stdout and stderr reporting
> in the next few days as per my earlier discussion and the FastCGI
> wiki topic.
>
> I will be concentrating on WMS support initially.
>

Thanks for looking out for me, Frank!  And I think it will benefit other
folks, including PHP users, who would like to leverage mapserver's WMS
and WFS to script their own OGC-ish services like the cross-database 
joining
WFS service I proposed the other day.

> I am looking into overhauling the connection pooling so that 
> connections to
> databases (such as SDE) can be cached over the life of the FastCGI 
> process
> instead of just the lifespan of a single map render.  I will try to 
> provide
> some details on my approach before I commit anything.
>

Would you consider an approach that would support the use case of 
mapscript
and shared connections?  Python and Perl's DBI modules are based on 
libpq,
so there is something in there that we can transform into a mapserver
postgis connection:

 >>> dsn = "dbname=postgis"
 >>> dbcon = psycopg.connect(dsn)   # Python database connection
 >>> postgis_layer.connect(dbcon)   # use existing connection

I'm not asking you to write the code under such a layerObj::connect
method, just to not close the door on such a thing.

Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies