[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12430517 ]
Knut Anders Hatlen commented on DERBY-418:
------------------------------------------
Thank you for addressing my comments, Mayuresh!
I think you misunderstood what I meant with the indentation (you're not the
first one to have problems with this). The files you have changed use tabs to
indent the code. The people who created the files used editors with tab stops
at four characters. Since your editor has tab stops at eight characters, and
you use space as indentation character, you end up indenting the code twice as
much as the surrounding code.
For instance, BaseActivation.java has this diff:
@@ -787,6 +791,7 @@
public final void markUnused()
{
inUse = false;
+ lcc.notifyUnusedActivation();
}
The line with inUse = false is indented with two tabs, which should be
equivalent to eight spaces. However, the line with lcc.notifyUnusedActivation()
is indented with 16 spaces, whereas it should have been on the same indentation
level as the previous line. This seems to be the case for all the changed lines.
Solution: Change the tab settings in your editor and reduce the indentation
level of the changed code. Since the surrounding code uses tabs, it would be
preferable that the changes used tabs as well, but if you choose to use spaces,
one tab character should match four spaces.
I'm sorry that I didn't comment on this before, but mixing of tabs and spaces
with incorrect tab width is one of those issues that you don't see when you
inspect the patch, only after you have applied the patch and read the source in
an editor.
> 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,
> derby418_v3.diff, derby418_v4.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
