[
https://issues.apache.org/jira/browse/DERBY-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564240#action_12564240
]
Daniel John Debrunner commented on DERBY-3368:
----------------------------------------------
As an aside one strange aspect is that if the Dependency is not added to the
manager due to an existing duplicate then it is still added to the list in the
StatementContext. This is pointless as the Dependency will not exist in the
manager and the purpose of the list in the statement context is to remove
dependencies on error.
> Threading issue with DependencyManager may cause in-memory dependencies to be
> lost.
> -----------------------------------------------------------------------------------
>
> Key: DERBY-3368
> URL: https://issues.apache.org/jira/browse/DERBY-3368
> Project: Derby
> Issue Type: Bug
> Components: Services
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> When a thread compiles a language prepared statement P a set of in-memory
> Dependency objects is created, e.g. if P accesses table A
> Dependency {P depends on A}
> When this Dependency is added to the dependency manager if an equivalent one
> (same provider and dependent) exists then the duplicate will not be added.
> The StatementContext keeps track of these added Dependency so that if the
> compilation fails the Dependency will be removed, comparing by the exact same
> Dependency object (not by equivalence).
> If a thread T1 compiling P fails, then another thread may try to compile P
> (same object). If this second thread T2 compiles successfully the following
> could happen:
> 1) T1 compiles P creates Dependency {P depends on A} in dependency manager
> 2) T1 fails to compile, but does not yet execute its cleanup
> 3) T2 compiles P successfully, attempts to add Dependency {P depends on A} to
> the manager but it is a duplicate so T1's version is left and T2's is not
> added.
> 4) T1 completes its cleanup and removes Dependency {P depends on A}
> 5) P no longer depends on A
> Concern is that the security system GRANT/REVOKE is based upon the dependency
> manager as well as correctness for indexes (e.g. this could cause a recompile
> to be missed for an INSERT table when an index is added).
> For this to actually happen there has to be a situation where one thread
> (connection) can compile a statement that another one fails on (and be
> compiling at near identical times). I haven't got a reproducible case yet,
> but I can get two statements to be compiling the same statement plan (P).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
