[
https://issues.apache.org/jira/browse/DERBY-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605115#action_12605115
]
Dag H. Wanvik commented on DERBY-2861:
--------------------------------------
I instrumented the code that sets referencedColumnMap to collect the thread
and the thread's
stacktrace when it sets it to null, and printed that as well as the current
thread and the stacktrace
when the error occurs:
I got these two stack traces that show how two threads get in each others way
here.
--->thread 1: Thread[Thread-10,5,main]
**
org.apache.derby.iapi.sql.dictionary.TableDescriptor.setReferencedColumnMap(TableDescriptor.java:381)
**
org.apache.derby.impl.sql.depend.BasicDependencyManager.clearColumnInfoInProviders(BasicDependencyManager.java:707)
**
org.apache.derby.impl.sql.compile.CreateViewNode.bindViewDefinition(CreateViewNode.java:290)
**
org.apache.derby.impl.sql.compile.CreateViewNode.bindStatement(CreateViewNode.java:181)
**
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:314)
** org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
**
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:794)
** org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
** org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
**
TestEmbeddedMultiThreading.executeStatement(TestEmbeddedMultiThreading.java:124)
** TestEmbeddedMultiThreading.access$100(TestEmbeddedMultiThreading.java:25)
**
TestEmbeddedMultiThreading$ViewCreatorDropper.run(TestEmbeddedMultiThreading.java:188)
** java.lang.Thread.run(Thread.java:619)
--->thread 2: Thread[Thread-5,5,main]
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1206)
at
org.apache.derby.iapi.sql.dictionary.TableDescriptor.getObjectName(TableDescriptor.java:796)
at
org.apache.derby.impl.sql.depend.BasicDependencyManager.getPersistentProviderInfos(BasicDependencyManager.java:681)
at
org.apache.derby.impl.sql.compile.CreateViewNode.bindViewDefinition(CreateViewNode.java:287)
at
org.apache.derby.impl.sql.compile.CreateViewNode.bindStatement(CreateViewNode.java:181)
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:314)
at
org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:794)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
at
TestEmbeddedMultiThreading.executeStatement(TestEmbeddedMultiThreading.java:124)
at
TestEmbeddedMultiThreading.access$100(TestEmbeddedMultiThreading.java:25)
at
TestEmbeddedMultiThreading$ViewCreatorDropper.run(TestEmbeddedMultiThreading.java:188)
at java.lang.Thread.run(Thread.java:619)
These lines in CreatViewNode#bindViewDefinition account for both thread stacks:
(2) ProviderInfo[] providerInfos = dm.getPersistentProviderInfos(apl);
// need to clear the column info in case the same table descriptor
// is reused, eg., in multiple target only view definition
(1) dm.clearColumnInfoInProviders(apl);
Thread 1 is excuting line marked (1), thread 2 is executing line marked (2).
> Thread safety issue in TableDescriptor
> --------------------------------------
>
> Key: DERBY-2861
> URL: https://issues.apache.org/jira/browse/DERBY-2861
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Environment: Tested on a dual-core 3GHz Pentium machine running
> Windows Vista Business, using JDK 1.4.2_13 and Derby trunk revision 548822.
> Reporter: Jeff Clary
> Attachments: TestEmbeddedMultiThreading.java
>
>
> A NullPointerException occurs in
> org.apache.derby.iapi.sql.dictionary.TableDescriptor.getObjectName when
> accessing the same object on many threads (each with its own connection).
> The attached test program starts N threads each creating and then dropping a
> separate view against the same source view, repeated M times. I can
> reproduce the problem with N=100 and M=100 on my machine, but not every run.
> An instance member named referencedColumnMap is checked for null at the top
> of the getObjectName method, but later when it is dereferenced it is null,
> because it was set to null by another thread. I am not sure what
> getObjectName is used for other than error reporting. I have considered a
> fix of just saving the non-null reference as a method variable, to avoid the
> later NullPointerException. But I don't know what unintended consequences
> this may have.
> When the test program does show the exception, the stack trace looks like
> this:
> java.lang.NullPointerException
> at
> org.apache.derby.iapi.sql.dictionary.TableDescriptor.getObjectName(TableDescriptor.java:758)
> at
> org.apache.derby.impl.sql.depend.BasicDependencyManager.getPersistentProviderInfos(BasicDependencyManager.java:677)
> at
> org.apache.derby.impl.sql.compile.CreateViewNode.bindViewDefinition(CreateViewNode.java:287)
> at
> org.apache.derby.impl.sql.compile.CreateViewNode.bind(CreateViewNode.java:183)
> at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:345)
> at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:119)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:745)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:568)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:517)
> at
> TestEmbeddedMultiThreading.executeStatement(TestEmbeddedMultiThreading.java:109)
> at
> TestEmbeddedMultiThreading.access$100(TestEmbeddedMultiThreading.java:10)
> at
> TestEmbeddedMultiThreading$ViewCreatorDropper.run(TestEmbeddedMultiThreading.java:173)
> at java.lang.Thread.run(Thread.java:534)
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
