Martin Desruisseaux wrote: > Andrea Aime a écrit : >> I can commit it. I was tghinking of rolling a separate method >> setCode(preparedStatement, int index, String code) >> so that subclasses can override the defult behavior and use setString >> instead. That should handle the IGN specific case. > > We can wait before making this method public (unless someone else need > it). The French mapping institute sent me their modified version of > DirectEpsgFactory a while ago, and the primary key is not the only > change (they also handle Unit of measurement differently). I have not > yet examined how much changes are needed in order to align our class > with their version.
Oh, in that case I'll commit the patch as is, and let you handle those modification as a whole. >> Hum, I don't know. Connection pools by default assume the connection >> will live forever, and allow for adding a validation query for >> connection verification prior to actual usage. >> With the patch the timeout is actually not needed anymore? > > I though that we still need to close the connection in order to give it > back to the pool... I think it is also what Jody told me when he was > working on threaded factories, unless I understood wrong. From > javax.sql.PooledConnection javadoc: > > "When an application closes a connection, it calls the Connection method > close. When connection pooling is being done, the connection pool > manager > is notified (...snip...) Thus, when an application closes its > connection, > the underlying physical connection is recycled rather than being > closed." > > But anyway, I'm fine if you apply the patch as is. It would be more or > less temporary (unless the community decides otherwise) since I'm trying > to adress those kind of issues since last week (I'm working on > CRSAuthorityFactories right now) but the work still not ready for a > merge. The approach I'm leading to is to close the connection after a > much shorter timeout (so actually giving it back to the pool). In case > we still have a connection lost, I'm tempted to make a second try after > some kind of SQLException (so avoiding the cost of testing the > connection in the common case where the connection still okay). Hum, interesting point. The issue I see is that we're doing the connection validation, whilst the pool is not, so if we give back the connection, the pool might return it back when we ask for another one. I guess we need to have the pool do the validation as well. I have to double check, this might mean we need to add a DBCP dependency on the actual modules so that we have a connection pool good enough to actually validate the connections. Cheers Andrea ------------------------------------------------------------------------------ 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
