[DERBY-6054] java.sql.SQLException: Exceeded maximum number of sections 32k in application with many setTransactionIsolation statements

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Not A Problem
• Affects Version/s: 10.8.2.2
• Component/s: Network Client

Environment

Linux vm (need to get more details). Problem is particular to this environment and does not fail on other hardware.

Fri Jan 04 13:41:47 MST 2013:
Booting Derby version The Apache Software Foundation - Apache Derby - 10.8.2.2 - (1181258): instance a816c00e-013c-074b-
b72a-000052798332
 sun.misc.Launcher$AppClassLoader@2e502e50

java.vendor=IBM Corporation
java.runtime.version=pxi32devifx-20090225 (SR9-0 +IZ44410+IZ44495)
java.fullversion=J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223ifx-20090225 (JIT enabled)
J9VM - 20090224_30451_lHdSMr
JIT - 20081112_1511ifx1_r8
GC - 200811_07

• Issue & fix info: Workaround attached
• Bug behavior facts: Embedded/Client difference, Seen in production
• Assignee: Katherine Marsden
• Reporter: Katherine Marsden
• Created: 25/Jan/13 21:46
• Updated: 11/Feb/13 21:27
• Resolved: 11/Feb/13 21:19

Description

An application that uses OpenJPA and WAS gets the exception below.
java.sql.SQLException: Exceeded maximum number of sections 32k
at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.client.am.Statement.executeUpdate(Unknown Source)
at org.apache.derby.client.am.Connection.setTransactionIsolationX(Unknown Source)
at org.apache.derby.client.am.Connection.setTransactionIsolation(Unknown Source)
at org.apache.derby.client.am.LogicalConnection.setTransactionIsolation(Unknown Source)
at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.setTransactionIsolation(WSRdbManagedConnectionImpl.java:4622)
at com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.setTransactionIsolation(WSJdbcConnection.java:2884)
at org.apache.openjpa.lib.jdbc.DelegatingConnection.setTransactionIsolation(DelegatingConnection.java:257)
at org.apache.openjpa.lib.jdbc.DelegatingConnection.setTransactionIsolation(DelegatingConnection.java:257)
at org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator.decorate(ConfiguringConnectionDecorator.java:95)
at org.apache.openjpa.lib.jdbc.DecoratingDataSource.decorate(DecoratingDataSource.java:100)
at org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:88)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connectInternal(JDBCStoreManager.java:879)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager.java:864)

Looking at the log every time a connection is opened there are two SET CURRENT ISOLATION STATEMENTS, presumably as the isolation is set and then again to reset it for the pool.

There are exactly 32767 of these for the session before the failure.

~/repro$grep 'SET CURRENT ISO' derby.log | grep 'Executing' |
grep 'SESSIONID = 9' | wc
32767 983010 8060682

Only the setTransactionIsolation statements do not seem to be getting garbage collected and teh sections reused. All in all the session has hundreds of thousands of statements that do not have a problem.
~/repro $ grep 'Executing' derby.log | grep 'SESSIONID = 9' |
wc
364906 30487228 297049149

Runtimeinfo was not revealing in terms of showing the statements building up. so there is more investigation to do.

Issue Links

• is related to: DERBY-6053 Client should use a prepared statement rather than regular statement for Connection.setTransactionIsolation
• is related to: DERBY-6068 Increase the arbitrary 32K limit imposed by DRDA on number of Sections used for open statements