db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4497) Incorrect double checked locking idiom used in VTIResultSet
Date Thu, 31 Dec 2009 09:11:29 GMT

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

Knut Anders Hatlen updated DERBY-4497:

      Issue & fix info: [Known fix]  (was: [Known fix, High Value Fix])
               Urgency: Normal  (was: Urgent)
    Bug behavior facts:   (was: [Wrong query result, Data corruption])

As far as I can see, the code in question is not currently in use, so I'm lowering the urgency
to normal.

> Incorrect double checked locking idiom used in VTIResultSet
> -----------------------------------------------------------
>                 Key: DERBY-4497
>                 URL: https://issues.apache.org/jira/browse/DERBY-4497
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:
>         Environment: OS: Redhat-5 Linux 2.6.18-92.el5
> JDK: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pxi3260sr4-20090219_01(SR4))
> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20090215_29883 (JIT
enabled, AOT enabled)
> J9VM - 20090215_029883_lHdSMr
> JIT  - r9_20090213_2028
> GC   - 20090213_AA)
> JCL  - 20090218_01
>            Reporter: Daniel Luo
>   Original Estimate: 0.08h
>  Remaining Estimate: 0.08h
> In method setSharedState of class VTIResultSet, double checked locking idiom is used.
But the field compileTimeConstants involved in the idiom is not declared with volatile modifier
which is incorrect. Simply add volatile modifier in field compileTimeConstants declaration
can quickly fix the problem. Below link and description explain the details.
> http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl
> "The double-checked locking idiom (also called the multithreaded singleton pattern) is
a trick designed to support lazy initialization while avoiding the overhead of synchronization.
Sometimes it doesn't work correctly since the writes initializing the object and the write
to the field storing the object instance can be reordered by the compiler or the cache, which
would have the effect of returning what appears to be a partially constructed object instance.
The result would be that we read an uninitialized object. In JVMs 1.5 or above, the use of
the volatile keyword in field declaration would eliminate the problems."

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message