[
https://issues.apache.org/jira/browse/DERBY-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor reassigned DERBY-6054:
--------------------------------------
Assignee: Kathey Marsden
> java.sql.SQLException: Exceeded maximum number of sections 32k in
> application with many setTransactionIsolation statements
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6054
> URL: https://issues.apache.org/jira/browse/DERBY-6054
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.8.2.2
> 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
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
