Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
10.2.2.0
-
None
-
Normal
-
Wrong query result
Description
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
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).
Attachments
Issue Links
- relates to
-
DERBY-2380 A statement plan holds onto resources such as its generated class even after it has been invalidated.
- Open
-
DERBY-3102 Statements are not removed from the cache, even when they are of no use, e.g. statements that reference a dropped table.
- Open