[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12430420 ]
Knut Anders Hatlen commented on DERBY-418:
------------------------------------------
+ } catch(StandardException e) {
+ throw StandardException.plainWrapException(e);
+ }
Since e already is a StandardException, there's no need to catch it and wrap it
in a StandardException.
It would also be good if there were a comment in addActivation() explaining why
we're iterating over the activations vector, and a comment in BaseActivation
saying that inUse is declared volatile to ensure it is visible when it has been
modified by the finalizer thread.
Have you considered the option where you set a volatile flag in
GenericLanguageConnectionContext from BaseActivation.markUnused() so that you
don't have to scan the activations vectors when there is no unused activation?
It would require adding a method to the LanguageConnectionContext interface
(for instance notifyUnusedActivation), but I think it is worth it since it
would remove the performance penalty that some (odd) applications could
experience with the current patch.
> 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, derby418_v1.diff, derby418_v2.diff
>
>
> 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
