Page History

--- Check the statement (query failed).
 
--- Cause: java.sql.SQLException: [0]:Failure to find statement; nested exception is com.ibatis.common.jdbc.exception.NestedSQLException:
 
--- The error occurred in maps/CommonSqlMap.xml.
 
--- The error occurred while applying a parameter map.
 
--- Check the Common.getIservSp-InlineParameterMap.
 
--- Check the statement (query failed).
 
--- Cause: java.sql.SQLException: [0]:Failure to find statement

If it is normal,

Tomcat log (version 6)
 
[0001][14:14:31 386][    2][    0] GET-CONNECTION[org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection] [1 ms]

How to check

After removing the comment at the bottom of the contents of the $CATALINA_HOME/conf/server.xml file, restart Tomcat and check $CATALINA_HOME/logs/tomcat.log.
 Before the change>
        <!--
        <Valve className="org.apache.catalina.valves.AccessLogValve"
                 directory="logs"  prefix="localhost_access_log." suffix=".txt"
                 pattern="common" resolveHosts="false"/>
        -->
 
After the change>
        <Valve className="org.apache.catalina.valves.AccessLogValve"
                 directory="logs"  prefix="localhost_access_log." suffix=".txt"
                 pattern="%a %b %t %s %D %r " resolveHosts="false"/>

Reference: http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html

Recommended Tomcat settings

• testOnBorrow
  + When getting a connection from the connection pool, the connection is validated
  + The default value is false, and the default value is generally used. If set to true, validationQuery is executed every time, so a slight performance decrease is expected.
• poolpreparestatement
  + Statement pooling is maintained for each connection in DBCP, so the application server (App) keeps the information compiled for the query. After that, it is possible to improve performance by repeating only the execute step without preparing the same query.

Return of used resource

Connection, Statement, and ResultSet allocated by the program must be explicitly closed after use. If it is not closed, resources are continuously allocated during the life cycle of the variable that declared the above resource, which results in unnecessary resource consumption.

If the connection is not closed, the connection will not be returned to the pool, so it will be unable to use it elsewhere.

Statement information is allocated and remained in memory not only on the application but also on the DB server while the session is maintained. Therefore, if the statement and the connection are not closed, this could be a problem for unnecessary resources are continuously allocated in the application, but the Query_Prepare memory area of the DB server also increases.

If the above resources are not explicitly closed, they are allocated in memory during the life cycle of the variable that declares the resource. If the life cycle ends, the resource is no longer referenced, so the JVM (Java Virtual Machine) and GC (Garbage Collector) will later release the resource. However, GC is generally the lowest priority thread. Therefore, it is difficult to predict when the GC releases the resource. In other words, it can not be released immediately because the life cycle of the variable is no longer referenced in the application, and the DB server keeps the information about the resource unless the GC releases it.

Therefore, it is recommended to close the used resource explicitly.

removeAbandoned="true"