Weblogic10.3.5 Database Connectivity Issues _weblogic

Solution Method:

To see if you are connected there is no release of the place, in the Http://localhost:7001/console deployment can be seen
Setting WebLogic Connection Pool properties inactive Connection Timeout;
Three, or you change the JDBC jar package

is WebLogic's inactive Connection Timeout property setting problem, the data volume of the database is too large, the SQL execution time is too long, and the property configuration value is 180 let me finish 0. Thank you, Laura.

0 is not a timeout.

Attached official documents:

The number of inactive seconds on a reserved connection before WebLogic Server reclaims the connection and releases it BAC K into the connection pool.

can use the Inactive Connection Timeout feature to reclaim leaked connections-connections this were not explicitly c Losed by the application. "This" is "not intended" to "be used" in "place of properly closing connections.

When set to 0, the feature is disabled.

MBean Attribute (does not apply to application modules):
Jdbcconnectionpoolparamsbean.inactiveconnectiontimeoutseconds

Minimum value:0

Maximum value:2147483647

A recent discovery of Weblogic10.3.5 database connectivity issues, first introduces a JDBC parameter inactiveconnectiontimeout, which is used to force the recycling of those compromised connections (connections that are not used for a long time, that are not properly released by the program), Avoid connection pooling because of a leak causing no connection to be available. Of course, this parameter is only auxiliary, the solution to the problem is to improve the application.

This article is related to this parameter, in earlier 8.1\9.2, when this parameter was set, the timer (the Internal Connection Pool maintenance Task) only cleaned up idle connections that were not in use for a long time (as can be seen from the name), which is unaffected for a connection running a long-running SQL execution. But I don't know which version to start with 10.3 (I'm testing 10.3.5), which is also a mandatory collection for long-running SQL connections (this is not reasonable, although it does not have much impact on the TX being performed). Debug a bit, found that SQL execution time is greater than 4*inactiveconnectiontimeout, when this SQL execution completes, will appear <BEA-001153> <forcibly releasing inactive Connection "weblogic.jdbc.wrapper.poolconnection_oracle_jdbc_driver_t4cconnection@1" back into the connection pool " Testds ", currently reserved by:java.lang.Exception such a mistake.


The thread is the internal task execution thread, which is currently in a blocked state, waiting for the connection to be reclaimed after SQL execution ends


"[Stuck] Executethread: ' For queue: ' Weblogic.kernel.Default (self-tuning) '" Daemon prio=2 tid=0x2c4d3400 nid=0x1a14 Waiting for monitor entry [0x


319BF000]


Java.lang.Thread.State:BLOCKED (on object monitor)


At Oracle.jdbc.driver.PhysicalConnection.rollback (physicalconnection.java:3896)


-Waiting to lock <0x0e6191d8> (a oracle.jdbc.driver.T4CConnection)


At Weblogic.jdbc.wrapper.Connection.forcedCleanup (connection.java:156)


At Weblogic.common.resourcepool.ResourcePoolImpl.timeoutInactiveResources (resourcepoolimpl.java:1955)


At Weblogic.common.resourcepool.resourcepoolimpl.access$8 (resourcepoolimpl.java:1916)


At Weblogic.common.resourcepool.resourcepoolimpl$resourcepoolmaintanencetask.timerexpired (ResourcePoolImpl.java : 2680)


At Weblogic.timers.internal.TimerImpl.run (timerimpl.java:273)


At Weblogic.work.selftuningworkmanagerimpl$workadapterimpl.run (selftuningworkmanagerimpl.java:528)


At Weblogic.work.ExecuteThread.execute (executethread.java:209)


At Weblogic.work.ExecuteThread.run (executethread.java:178)


The thread executes the thread for the application, the thread is currently running, and he is blocking (blocking the object is t4cconnection) the internal task execution thread


"[Stuck] Executethread: ' 0 ' for queue: ' Weblogic.kernel.Default (self-tuning) '" Daemon prio=2 tid=0x2c7b4c00 nid=0x1100 R unnable [0x2cf7e000]


Java.lang.Thread.State:RUNNABLE


At Java.net.SocketInputStream.socketRead0 (Native method)


......


At Oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout (oraclestatement.java:1315)


At Oracle.jdbc.driver.OraclePreparedStatement.executeInternal (oraclepreparedstatement.java:3576)


At Oracle.jdbc.driver.OraclePreparedStatement.execute (oraclepreparedstatement.java:3677)


-Locked <0x0e6191d8> (a oracle.jdbc.driver.T4CConnection)


At Oracle.jdbc.driver.OraclePreparedStatementWrapper.execute (oraclepreparedstatementwrapper.java:1374)


At Weblogic.jdbc.wrapper.PreparedStatement.execute (preparedstatement.java:102)


At Com.bea.cs.test.jdbc.DriverTest.inactiveTimeoutTest (drivertest.java:537)


At Jsp_servlet.__ds._jspservice (__ds.java:86)


From the above thread stack, you can see that the internal task thread is calling the connection rollback, that is, rolling back the local transaction on the connection. If the connection used on the application thread is set to Auto commit, the SQL execution will not be rollback, or the SQL will be rollback (in the global transaction, the connection used by a transaction branch must be a non-auto commit), Therefore, this problem has a greater impact on the application of global transactions.


Here we look at the point at which the connection is recycled and why it appears between 3-4 Inactiveconnectiontimeout. When the internal task executes and the inactiveconnectiontimeout point is found, it calls the Timeoutinactiveresources () method to begin the connection cleanup. So why are the connections that are executing SQL flagged as inactive connections? This involves the three flags of the connection state, respectively: Conn_in_use,connused,hang_state, where the three flags are the key (Getused () and setused () methods are used for flag-bit manipulation and reading, If getused () returns false for a connection, the connection is cleaned up. Let's take a look at the change in the flag bit: When SQL starts executing, the Preinvokehandler is set by the three flag bits.


The initial values are as follows:


Conn_in_use-->true


Hang_state-->conn_state_in_use


Connused-->true


The first inactiveconnectiontimeout check, getused returns True, and Setused (false) is called, and the flag bit changes as follows:


Conn_in_use-->true


Hang_state-->conn_state_idle_suspect


Connused-->true


The second inactiveconnectiontimeout check, getused returns True, calls Setused (false), and the flag bit changes as follows:


Conn_in_use-->false


Hang_state-->conn_state_hang_suspect


Connused-->false


The third inactiveconnectiontimeout check, getused returns True,


Hang_state-->conn_state_in_use (from Conn_state_hang_suspect into Conn_state_in_use)


Call Setused (false) at the same time, and the flag bit changes as follows:


Conn_in_use-->false


Connused-->false


Hang_state-->conn_state_idle_suspect (from Conn_state_in_use into Conn_state_idle_suspect)


The fourth time inactiveconnectiontimeout check, getused returns False, and begins to recycle the connection.


From the above change point of view can be seen from the first to the fourth check went through the full 3 inactiveconnectiontimout cycle, and from the SQL execution to the first checkpoint, this time is less than a inactiveconnectiontimeout, So the point at which the connection begins to be reclaimed is between 3-4 inactiveconnectiontimeout.


Java Software Learning Center with your common learning Java development, if there are other discoveries can contact me.