Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Fixed stale database connection release #1526
getAutoCommit, rollback and commit can throw exceptions on stale connections, which was preventing a correct connection release. (c.releaseFunc() was never called in that case)
That part of the code uses the Helpers.tryo() a lot, which is also a catch-all directive. Thats why I was following the already implemented pattern. In this case it would be possible to narrow the exception to java.util.SQLException. If we do that, however, the connection would not be released correctly, in the event of another Exception. As I mentioned in the mailing-list, the non-released connection will mess up the whole application.
We could also put the call to release in finally clause, so a non-SQLException will get thrown to the caller.
So I leave it to you guys to make a call on that. And I can implement either change, if requested.
I think you misunderstood the pattern a bit. Or perhaps the pattern is just misused here.
This code will eat all exceptions, only logging them at the debug level.
It may be true that
Let's do that. (Put the release in finally.) I think that's the best compromise we have right now with the way this code is structured.
Yes it is misused here as a swallow-all. The method
Therefore, I narrowed the exception to SQL and introduced the finally clause as we discussed before, and changed the log-level to error, so the user is informed either way that the connection-release was not going well. As you said, that may be a good compromise, without having to change too much in this class for that particular case.