[jira] [Updated] (DERBY-3368) Threading issue with DependencyManager may cause in-memory dependencies to be lost.

["Kathey Marsden (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kathey Marsden updated DERBY-3368:
----------------------------------

      Issue & fix info:   (was: High Value Fix)
    Bug behavior facts: Wrong query result
                Labels: derby_triage10_10 derby_triage10_5_2  (was: derby_triage10_5_2)

Taking off of High Value Fix until we have a reproduction.  Adding wrong results which could occur with this issue.

                
> 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
>    Affects Versions: 10.2.2.0
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>              Labels: derby_triage10_10, derby_triage10_5_2
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira