If you customize the database by customization, forgetting to close the connection will cause resource exhaustion. In such a case, it is easier to identify the cause by monitoring the connection pooling number.
The connection information of the database is described in the configuration file wagbyapp \ conf \ server.xml in the automatically generated application (wagbyapp) as follows.
<Resource name="jdbc/jfc" auth="Container" type="javax.sql.DataSource" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/xxxdb?useUnicode=true&relaxautoCommit=true" username="xxx" password="xxx" maxActive="24" maxIdle="8" maxWait="2000" defaultAutoCommit="false" />
Please change the last line of this setting "defaultAutoCommit =" false "/>" as shown below and restart the application.
defaultAutoCommit="false" removeAbandoned="true" removeAbandonedTimeout="3600" logAbandoned="true" />
This setting is to automatically close when there is a connection which is not closed for the time specified by removeAbandonedTimeout (3600 seconds = 1 hour in the above).
Also, by specifying logAbandoned = "true", the stack trace at the time of acquiring the closed connection is output.For details, please see the following.
I will explain how to check the number of connections used in connection pooling.The connection here includes both java.sql.Connection and Hibernate Session.
Add the following settings to the configuration file wagbyapp \ webapps \ [application name] \ WEB - INF \ web.xml.
<!-- CheckDataSourceFilter Configuration --> <filter> <filter-name>CheckDataSourceFilter</filter-name> <filter-class>jp.jasminesoft.jfc.filter.CheckDataSourceFilter</filter-class> <init-param> <param-name>checktype_before</param-name> <param-value>All</param-value> <!-- All or ActiveOver0 --> </init-param> <init-param> <param-name>checktype_after</param-name> <param-value>All</param-value> <!-- All or ActiveOver0, ChangeBeforeAfter, OverBeforeToAfter --> </init-param> </filter> <filter-mapping> <filter-name>CheckDataSourceFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
When this description is added, the status of the connection pool is output to the log before and after processing the request to the web server. Active is the number of connections currently in use and idle is the number of pending connections.
If active is greater than 0 although processing is not done at all, it is considered that connection closure processing has leaked.
In the following example, since active is 0 before and after before and after, it shows that there is no omission of connection closing process.
[INFO jp.jasminesoft.jfc.filter.CheckDataSourceFilterdoFilter] before GET /wagby/showListJuser.do active=0 idle=2 [INFO jp.jasminesoft.jfc.controller.DbShowListBaseControllerperform_db] (admin@0:0:0:0:0:0:0:1) showListJuser|Search [INFO jp.jasminesoft.jfc.filter.CheckDataSourceFilterdoFilter] after GET /wagby/showListJuser.do active=0 idle=2
I will explain the behavior of the getConnection and closeConnection methods done by Wagby's internal DbBaseController class.This is only getting java.sql.Connection, not Hibernate Session.
Add the following settings to the configuration file wagbyapp \ webapps \ [application name] \ WEB - INF \ classes \ log4j.properties.
When this setting is done, the following logs are output when Wagby acquires a connection from the connection pool and closes it.
[DEBUG jp.jasminesoft.jfc.controller.DbBaseControllergetConnection] (admin) Connection object has been reassigned. [INFO jp.jasminesoft.jfc.controller.DbShowListBaseControllerperform_db] (admin@0:0:0:0:0:0:0:1) showListJuser|Search [DEBUG jp.jasminesoft.jfc.controller.DbBaseControllercloseConnection] (admin) database connection is closed.
In this example, you can see that connection acquisition (reassigned) and release (closed) are done in sets.This is a normal log.