Thanks, Gary. I agree with everything below. I think it's best to just leave things as they are.
Phil On Mon, Feb 12, 2024 at 7:25 PM Gary Gregory <garydgreg...@gmail.com> wrote: > I've used many JDBC drivers from different vendors, FOSS and > proprietary, and if I've learned one thing, it is that each is its own > world within the universe of the DBMS it operates in. > > It is impossible to write a generic tool; they all end up providing > plugins for DB-specific features, sure, but those plugins invariably > also account for behavioral differences between drivers. > > You can't even rely on all JDBC APIs to be implemented that one would > imagine should be "core" to the functionality. I've seen such APIs > just stubbed to throw exceptions. This is especially common for > metadata-related APIs. > > Relying on SQL states is pretty hopeless IMO. I've had to allow custom > configs in apps to try and figure out the driver and connection state > from exception class names and exception message contents because you > can't rely on SQL states, and if you do then you realize that > different drivers use different states in similar contexts, so then > you allow for customization of _that_ too, bleh. > > All of this is to say that it feels dangerous to remove any hook we > provide. > > I just can't see a reliable way to detect a broken Connection unless > it's a detectable network breakage (if a socket or IO exception is the > root cause). > > The bottom line is that connections are really expensive to create, > and should only be thrown away if you know for sure it's gone bad. I'd > never want to throw away a connection that is fine from the server POV > but the driver throws exception X because for whatever reason, is > reusable, but we throw it away. > > HTH, > Gary > > On Mon, Feb 12, 2024 at 2:42 PM Phil Steitz <phil.ste...@gmail.com> wrote: > > > > In DBCP-595, a change is suggested to force close connections when a > fatal > > SQL exception has occurred. As of Version 2.2 of DBCP, fatal exceptions > > are tracked and the fastFailValidation property can be set to fast fail > > validations when a fatal exception has occurred on a connection. This > > change would obsolete that property, as it would make the pool close the > > connection immediately. > > > > I see two pros for this change and one con. > > > > Pros: > > 0) Bad connection is destroyed immediately > > 1) Works when validation is turned off > > > > Con: > > Incorrect SQL states returned by drivers or transient failures may cause > > over-zealous purging of connections. > > > > I vaguely recall the "Con" as the reason why we implemented > > fastFailValidation instead of direct close on these failures, but I can't > > find the discussion in the archives. > > > > Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
