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.
