[
https://issues.apache.org/jira/browse/DERBY-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-6054:
----------------------------------
Issue & fix info: Workaround attached
WORK AROUND:
The user was able to work around the issue by reducing the number of
setTransactionIsolation statements by making the WAS default isolation and the
OpenJPA isolation match.
The statement log showed a large number of setTransactionIsolation statements
toggling from UR to RR.
"After changing transaction isolation level on WAS datasource to be equal with
SwKBT OpenJPA, I managed to get rid of large number of transaction UR, RR calls.
WAS datasource transaction isolation level needs to match OpenJPA
openjpa.jdbc.TransactionIsolation.
If not, it will invoke large number of setTransactionIsolation calls.
WAS datasurce transaction isolation level is configurable with property
webSphereDefaultIsolationLevel:
http://www-01.ibm.com/support/docview.wss?uid=swg21224492
"
> 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
>
> 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
