[
https://issues.apache.org/jira/browse/DERBY-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3368:
----------------------------------
Derby Categories: [High Value Fix]
This could potentially result in a corrupt index and wrong results so marking
as a high value fix candidate.
> 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.
