On 7/23/15 4:18 PM, Bernd Eckenfels wrote: > Hello, > > I noticed that with Oracle drivers you cannot "kill" a busy connection > by closing it (since close(), _getPC(), isOpen() and stmt.close() all > will synchronize on the (busy) physical connection. > > I noticed this in a custom persistence layer, so I thought to check out > if DBCP handles this situation.
DBCP does nothing special itself. It relies on JDBC drivers to open and close connections. > > I have a test program here: > > https://gist.github.com/ecki/345ee08ac97820972fe7 > > First of all it does not log DBCP messages. I am not sure what is > needed to get it going. As you can see in the output the deliberate > debug() message is printed so the general LogFactory should be set up. DBCP itself generates very few log messages. You should be getting those. See below, though, for what you are looking for. > > When I run the program with acfg.setRemoveAbandonedTimeout(12) it > suceeds, since the c3 is only idle for 10s. When I run it with (4) it > will (so it seems) close the connection and I get a exception on next > use. However I dont see a log message about the abandoned connection > and the usage tracking. Ideas? Do you see the abandoned object stack trace on the console (System.out)? The abandoned trace is not logged by DBCP. It is Commons Pool that generates the abandoned trace and writes it to the Printwriter configured via its setLogWriter method. The default is System.out. > > A second thing, from the abandoned tracker I had the impression the > usage is counted at the begin of exec. Correct. > So if a execution takes 20s as > in my case, it should be considered abandoned. But it seems not to be > the case. Is it recognizing it is busy when the exec does not return? No, it will try to close the connection when the idle object evictor runs. If the close raises an exception, you should see a stack trace on System.err. You don't see that? Phil > If this is the case, is there also a way to kill/destroy connections > beeing used too long? > > Gruss > Bernd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
