db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (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 16:04:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429442 ] 
Daniel John Debrunner commented on DERBY-418:

The alternate way to phrase it  is:

Can you guarantee no deadlocks from using synchronization in the finalize method?

Closing an activation in the finalize() methods is going to hit a lot of synchronized blocks,
there just seems endless potential
for deadlocks, especially when the connection may be in any state, not being used, rolling
back, preparing a statement, executing a statement, being shutdown by an unrelated error,
being finalized itself, etc. etc.. This is then further compilcated by the fact the the order
of execution within finalization is not guaranteed, if I have a chain of objects A,B,C the
order they are finalized is not guaranteed, could be BAC, could be CBA, could be by different
finalize threads.

So given that, how easy is it to show the locking ordering is consistent?

If you prove there is no possible chance of deadlocks, how is this enforced going forward?
Does every change to any sycnhronized block have to go through a full review of possible implications
with a single finalize method in EmbededResultSet?

Maybe it's just me, but getting no synchronization in a finalize() method seems to be a nice
simple rule, that doesn't require a proof for on-going changes in the engine. I suggested
some possible changes to fix this in DERBY-1142 and noted them above, are there any issues
with those?

> 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