Closed jdeck88 closed 8 years ago
okay, so I'm pretty sure I know where the issue is coming from, however I think we need to rethink how we access the db.
At a minimum, I think we should start using something like apache commons DBUtils or spring-jdbc which will eliminate a lot of try/catch blocks and handle closing of ResultSets, Statements, and Connections. I'm also curious if there would be an advantage to going to something like an ORM, but it might not be work the effort to do that. I'll look into it a bit more.
On Tue, Mar 8, 2016 at 4:12 AM, John Deck notifications@github.com wrote:
Assigned #10 https://github.com/biocodellc/biocode-fims-commons/issues/10 to @rodney757 https://github.com/rodney757.
— Reply to this email directly or view it on GitHub https://github.com/biocodellc/biocode-fims-commons/issues/10#event-580705259 .
okay, so I pushed a fix that should slow down the too many connection issue for now, however the problem is not completely fixed. Will resolve the rest of the unclosed connection issues with a refactor of how we access the db as mention in my previous comment.
On Wed, Mar 9, 2016 at 11:41 AM, Rj Ewing ewing.rj@gmail.com wrote:
okay, so I'm pretty sure I know where the issue is coming from, however I think we need to rethink how we access the db.
At a minimum, I think we should start using something like apache commons DBUtils or spring-jdbc which will eliminate a lot of try/catch blocks and handle closing of ResultSets, Statements, and Connections. I'm also curious if there would be an advantage to going to something like an ORM, but it might not be work the effort to do that. I'll look into it a bit more.
On Tue, Mar 8, 2016 at 4:12 AM, John Deck notifications@github.com wrote:
Assigned #10 https://github.com/biocodellc/biocode-fims-commons/issues/10 to @rodney757 https://github.com/rodney757.
— Reply to this email directly or view it on GitHub https://github.com/biocodellc/biocode-fims-commons/issues/10#event-580705259 .
ok, let me know what you recommend after looking at options and how much time it will take to code it for each.
On Tue, Mar 8, 2016 at 7:57 PM, RJ Ewing notifications@github.com wrote:
okay, so I pushed a fix that should slow down the too many connection issue for now, however the problem is not completely fixed. Will resolve the rest of the unclosed connection issues with a refactor of how we access the db as mention in my previous comment.
On Wed, Mar 9, 2016 at 11:41 AM, Rj Ewing ewing.rj@gmail.com wrote:
okay, so I'm pretty sure I know where the issue is coming from, however I think we need to rethink how we access the db.
At a minimum, I think we should start using something like apache commons DBUtils or spring-jdbc which will eliminate a lot of try/catch blocks and handle closing of ResultSets, Statements, and Connections. I'm also curious if there would be an advantage to going to something like an ORM, but it might not be work the effort to do that. I'll look into it a bit more.
On Tue, Mar 8, 2016 at 4:12 AM, John Deck notifications@github.com wrote:
Assigned #10 https://github.com/biocodellc/biocode-fims-commons/issues/10 to @rodney757 https://github.com/rodney757.
— Reply to this email directly or view it on GitHub < https://github.com/biocodellc/biocode-fims-commons/issues/10#event-580705259
.
— Reply to this email directly or view it on GitHub https://github.com/biocodellc/biocode-fims-commons/issues/10#issuecomment-194104833 .
John Deck (541) 914-4739
okay, for now I just did a minor refactor to the Database class which should make it much harder to forget to close the connections.
Users not able to login and the following message is showing up in logs:
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Data source rejected establishment of connection, message from server: "Too many connections" at sun.reflect.GeneratedConstructorAccessor434.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1013)
We need to track down connections that are not closing... We did this a couple of months ago and this is the first time this has shown up since the refactor but wondering if some of the refactored code is not closing connections properly?
John