openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Graham <jool...@gmail.com>
Subject Re: connection leak after sql exception
Date Thu, 30 Apr 2009 00:58:42 GMT
More information, in case it's helpful:

* I'm using JTA through Spring Transactions.
* Here's a copy of my persistence.xml:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="myPU" transaction-type="JTA">
    <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
    <jta-data-source>puDataSource</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
      <property name="openjpa.jdbc.SynchronizeMappings"
value="buildSchema(ForeignKeys=true, PrimaryKeys=true)" />
    </properties>
  </persistence-unit>
</persistence>

* I've experimented with different ConnectionRetainMode settings, but
nothing seems to change this behavior
* My datasource is a connection pool -- do I have to explicitly inform
OpenJPA of this via the ConnectionDriver property?  I.e., should I be
using a DBCP driver?


Any help would be greatly appreciated.


On Fri, Apr 24, 2009 at 2:32 PM, Julian Graham <joolean@gmail.com> wrote:
> Hi everyone,
>
> I'm using OpenJPA 1.2.1, and my application server (Glassfish 2.1) is
> very consistently reporting a connection leak related to a call that
> causes a SQL exception to be thrown (the log prints out a stack trace
> of the initiation of the leaked connection).  The exception occurs
> because my mapping is inconsistent with the database schema (I'm using
> MySQL 5.1 and have a column that should have been created as
> auto_increment but wasn't).  This doesn't happen at any other time or
> with any other JPA implementation.  The original exception stack trace
> is:
>
> <openjpa-1.2.1-r752877:753278 nonfatal general error>
> org.apache.openjpa.persistence.PersistenceException: Field 'ID'
> doesn't have a default value {prepstmnt 5499982 INSERT INTO
> User_Session (Logged_In_Time, Logged_Out_Time, USER_ID) VALUES (?, ?,
> ?) [params=(Timestamp) 2009-04-24 13:25:07.026, (null) null, (long)
> 102]} [code=1364, state=HY000] FailedObject: [REDACTED] at
> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232)
> at
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197)
> at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102) at
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:72) at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:131)
> at
> org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:82)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72)
> at
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:543)
> at
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:105)
> at
> org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
> at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89)
> at
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717)
> at
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130)
> ... 85 more
>
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Field
> 'ID' doesn't have a default value {prepstmnt 5499982 INSERT INTO
> User_Session (Logged_In_Time, Logged_Out_Time, USER_ID) VALUES (?, ?,
> ?) [params=(Timestamp) 2009-04-24 13:25:07.026, (null) null, (long)
> 102]} [code=1364, state=HY000] at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:192)
> at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:57)
> at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:866)
> at
> org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151)
> at
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120)
> ... 95 more
>
>
> And here's the stack trace of where Glassfish thinks the connection got leaked:
>
> com.sun.enterprise.resource.AbstractResourcePool.setResourceStateToBusy(AbstractResourcePool.java:301)
> com.sun.enterprise.resource.AbstractResourcePool.internalGetResource(AbstractResourcePool.java:578)
> com.sun.enterprise.resource.AbstractResourcePool.getResource(AbstractResourcePool.java:443)
> com.sun.enterprise.resource.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:248)
> com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:176)
> com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:327)
> com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:189)
> com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
> com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
> com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:108)
> org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:106)
> org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:87)
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connectInternal(JDBCStoreManager.java:941)
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager.java:926)
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.retainConnection(JDBCStoreManager.java:216)
> org.apache.openjpa.kernel.DelegatingStoreManager.retainConnection(DelegatingStoreManager.java:163)
> org.apache.openjpa.kernel.BrokerImpl.retainConnection(BrokerImpl.java:3710)
> org.apache.openjpa.kernel.BrokerImpl.beginStoreManagerTransaction(BrokerImpl.java:1283)
> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1968)
> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1908)
> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1679)
> org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:989)
> org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:592)
>
>
> So clearly I need to fix my mapping, but is there anything I can do to
> prevent a connection leak under these circumstances?
>
>
> Thanks,
> Julian
>

Mime
View raw message