db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode
Date Mon, 21 Aug 2006 17:48:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429473 ] 
Andreas Korneliussen commented on DERBY-418:

Assuming the Derby embedded JDBC driver is thread-safe, it should be safe for a result set
to call its own close() method in its finalizer. If you get a dead-lock in the finalizer,
it proves that it is also possible to write a multithreaded program which gets deadlocks when
calling ResultSet.close, and derby then is not really MT-safe.

If this happens, I think it is better to fix the embedded driver so that it really becomes
MT-safe, than avoiding synchronization in the finalizer threads.

As for the suggested change in 1142, I would note that If there is no synchronization in the
finalizer, and you set a field in a object from it, there is no guarantee that other threads
will see the modification of the field (unless, I think, it is volatile). However, I think
Mayuresh has been working on this issue, so maybe he has tried that approach?

Another approach could be to use a WeakHashMap to store the activations in, instead of a Vector.
If all objects referring to the activation have been garbage collected, the activation will
be removed from the WeakHashMap.

> outofmemory error when running large query in autocommit=false mode
> -------------------------------------------------------------------
>                 Key: DERBY-418
>                 URL: http://issues.apache.org/jira/browse/DERBY-418
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:
>         Environment: I can reproduce this problem on Win2k/ T42 laptop. jdk141. 
>            Reporter: Sunitha Kambhampati
>         Assigned To: Mayuresh Nirhali
>             Fix For:
>         Attachments: AutoCommitTest.java
> On the derby-user list,  Chris reported tihs problem with his application and also a
repro for the problem.  I am logging the jira issue so it doesnt get lost in all the mail.
> ------from chris's post----------
> I'm running a set of ~50000 queries on one table, using inserts and updates, and i want
to be able to roll them back so i turned off autocommit using setAutoCommit(false).  As the
update runs, the memory used by the JVM increases continually until i get the following exception
about 20% of the way through:
> ERROR 40XT0: An internal error was identified by RawStore module.
>    at org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
>    at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java)
>    at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java)
>    at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java)
>    at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java)
>    at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java)
>    at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java)
>    at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java)
>    at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java)
>    at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java)
>    at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java)
>    at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java)
>    at org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java)
>    at org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java)
>    at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java)
>    at org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java)
>    at org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java)
>    at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java)
>    at org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java)
>    at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java)
>    at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java)
>    at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java)
>    at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java)
>    at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java)
>    at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java)
>    at vi.hotspot.database.DataInterface._query(DataInterface.java:181)
>    at vi.hotspot.database.DataInterface.query(DataInterface.java:160)
>    at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518)
>    at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619)
>    at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924)
>    at java.lang.Thread.run(Thread.java:534)
> vi.hotspot.exception.ServerTransactionException
>    at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555)
>    at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619)
>    at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924)
>    at java.lang.Thread.run(Thread.java:534)
> Derby is running in standalone mode. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message