[Mapserver-dev] FastCGI and MapServer 4.4

[Fernando S.]

Hi,
    It's very nice.
    I started to write something for maporaclespatial some weeks ago. I 
liked the fastcgi idea but when do you intend to include this feature in 
the code? In the next version? 4.4 or 4.6?
    I intend to start write oracle/fastcgi in the next week. But I don't 
know if I can to finish until October. So, what can I follow? Exist any 
step by step or a how to use for fastcgi?
    Any hints?
    Sorry my english.


----------------------------------------------------------------
Fernando Simon - simon at inf.univali.br
G10 - Laboratorio de Computacao Aplicada
http://g10.cttmar.univali.br
----------------------------------------------------------------



Frank Warmerdam wrote:

> Smith, Michael ERDC-CRREL-NH wrote:
>
>> Frank,
>>
>> What extra would it take to extend the connection pooling to Oracle.  
>> We may be able to provide that.
>> If not for 4.4, then for 4.5.
>
>
> Mike,
>
> My intention is to define fairly clear instructions on how to take 
> advantage
> of a "new" connection pooling API and those instructions should make 
> it pretty
> clear how it could be used.  Basically, I am looking at an API like this:
>
> void MS_DLL_EXPORT *msConnPoolRequest( layerObj *layer );
> void MS_DLL_EXPORT *msConnPoolRelease( layerObj *layer, void * );
> void MS_DLL_EXPORT  msConnPoolRegister( layerObj *layer,
>                                         void *connect_handle,
>                                         void (*close)( void * ) );
> void MS_DLL_EXPORT  msConnPoolMapDrawComplete();
> void MS_DLL_EXPORT  msConnPoolFinalCleanup();
>
> Particular format providers that want to support connection pooling will
> call msConnPoolRequest() with their layer.  The connection pooling code
> will look at the CONNECTION and CONNECTIONTYPE string, and see if 
> there is
> an existing handle associated with that pair.  If so, it will be returned
> (as a void *).
>
> If not, the provider establishes a connection and then registers it with
> msConnPoolRegister(), along with a function to be called when it 
> should be
> closed.
>
> When the LayerClose function is called for the provider, it would call
> msConnPoolRelease() and the connection pooling code would decide whether
> to invoke the low level close() or not.
>
> The connection pooling API would inspect some keyword(s) on the layer to
> determine whether to keep a connection alive, or let it close immediately
> after the last release against it.  I expect to use PROCESSING options 
> for
> this for now, though we might introduce a first class keyword for this
> at a later date.
>
> So, I believe that updating particular providers such as the Oracle, SDE,
> PostGIS, or OGR ones would be pretty straight forward.  The main issue 
> would
> be that it be done by some who can test if the code changes work.  
> Ideally the
> Oracle connecton maintainers would implement (or at least test) 
> changes for
> this.
>
> The actual work is likely not enough to justify cutting a contract of 
> some
> kind if that is what you are thinking.
>
> Best regards,