db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tiago R. Espinha (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3368) Threading issue with DependencyManager may cause in-memory dependencies to be lost.
Date Mon, 13 Jul 2009 12:47:15 GMT

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

Tiago R. Espinha updated DERBY-3368:

    Urgency: Normal

Triaged for 10.5.2. 

Assigned Normal urgency.

> 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
> 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.

View raw message