db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (DERBY-6054) java.sql.SQLException: Exceeded maximum number of sections 32k in application with many setTransactionIsolation statements
Date Mon, 11 Feb 2013 21:21:12 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mamta A. Satoor closed DERBY-6054.
----------------------------------

    Resolution: Not A Problem

Created DERBY-6068(Increase the arbitrary 32K limit imposed by DRDA on number of Sections
used for open statements) so that in case if garbage collection is not happening fast enough
or user is not closing the statements right away, we won't run into 32K limitation.
                
> 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

Mime
View raw message