MS RFC 22a: Feature cache for long running processes and query processing (update)

[Tamas Szekeres]

2007/6/25, Howard Butler <hobu.inc at gmail.com>:
> - The proposal doesn't state whether or not a cache layer will
> participate in the connection pool.  Is the handle to a cache layer
> intended to be kept alive like other connection handles across
> requests (ala FastCGI or some sort of always-on MapScript stuff)?
> Would it be reasonable to keep a connection handle to the
> "datasource" of all of the cache layers in the connection pool and
> then pull out references to already active cache layers?

According to our recent IRC conversation we would rather keep the
state of the cache preserved across the various sessions and map
creations. I think if the in-process state preservation is sufficient
than it could be easily handled inside the caching provider.

However it seems that the existing connection pooling mechanism cannot
be utilized for this purpose since the preserved objects are
distinguished based on the connection parameter and it cannot serve
the same object for different threads.

To implement this kind of functionality I could imagine taking out the
cache related parameters into a separate struct and use a global
hashtable to store the various cache state instances. The user should
explicitly specify which instance should the layer use. For example:

PROCESSING "cache_instance=cache1"

Where "cache1" is the key to get the cache state from the global hashtable.
The provider would use the necessary locks when accessing the global
cache, and msCleanup would destroy the cache when the process
terminates.

IMHO, however, it would be highly beneficial to establish a common
support for the long term state preservation in mapserver. Any of the
providers could push objects into a common repository and mapserver
would be responsible to free up the objects when the process
terminates.

Best regards,

Tamas