[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429483 ] Daniel John Debrunner commented on DERBY-418: ---------------------------------------------
I'd assumed that you were going to go in at a lower level than ResultSet.close(). ResultSet.close() is thread safe, but think of the consequences of calling ResultSet.close() from a finalizer. - The finalizer thread will block until the application thread executing a JDBC method on another object in the same connection completes the call. Worst case is the application thread is executing a query that takes several hours. Now the synchronization in the finalize method has resulted in the finalize thread stalling for a few hours, not good for the VM. - What if the garbage collector thread is running because the application thread, using the same connection, requires memory, now you have created a deadlock , the application thread is waiting on the JVM to get memory, the vm finalizer thread is waiting on the application thread to complete its JDBC method call. Not sure of the guarantee of the unsynchronized field being set. Are you saying that field will never be seen as set, or that the setting may not be seen for some time? The activation being in the Vector is not an issue, so replacing it with a WeakHashMap doesn't help. Code needs to be executed against the activation in order to clean it up, just letting it be garbage collected is not enough. The current scheme was set up to be simple, only a single thread active in a connection at a single time, and to avoid the jvm deadlocks that wer seen when the activations were cleaned up directly in the finalize thread (since it breaks the simple rule, only a single thread active in a connection). > 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
