[ 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: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. > jdk141. > Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > 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. > (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > ------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
