Andrea your patch sounds similar to the work I did in the referencing 
module; where everything was moved over to DataSource internally; and a 
connection was created as needed. It may not be directly similar since a 
pool of workers was kept each with a connection and cache; but they 
would be retired if found to be in error.
> So I went for a compromise:
> - the classes receive a DataSource instead of a single connection
> - the access to the connection is encapsulated into a single method
>    that checks the connection status before returning it. If the
>    connection is corrupt, it's discarded and a new one is gathered
>    from the data source
> - same goes for prepared statements that are cached as fields (
>    or inside a map), we need to check the connection attached to
>    them before actually using them, and ditch the whole set of
>    prepared statements and connection in case of corruption (and
>    start over).
> Checking is done as in most connection pools, by running a user
> provided statement , different for every database, that is at the
> same time fast, while forcing a communication with the server.
>   
Okay this sounds like code I am familiar with.
> The patch has been tested against a PostgreSQL authority, so that
> I could check the code is able to recover after a database restart
> while the authority was running (this is a check of the ability
> of the authority to replace its connection and prepared statements
> once they get corrupt).
>
> The public API of the sql authorities is not broken by the patch,
> new constructors have been created as needed and the old ones, taking
> a single connection, have been bridged using a fake, single connection
> DataSource.
>
> Given that the original jira issue received no attention so far, and
> that the referencing modules are currently unmantained in GeoTools,
> I'm asking a PSC perspective on the matter, and permission to commit
> on those modules  (referencing, epsg-hsql, epsg-posgtgres)
> on trunk and 2.5.x
>   
That sounds fine; I am available to review your patch after it is applied.
> PS: I was unsure which of the two sql authority hierarchies to patch,
>      if the current one, or the replacement one that uses the mediators.
>      Unfortunately I found out that the second one does not pass
>      various tests to start with, so I decided to go on the safe side
>      and patch the deprecated but working classes instead. A very
>      similar patch can be cooked for the other hierarchy.
>   
Thanks for that; I am still waiting for review on those last failed tests.

Jody

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to