[
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: 10.5.3.0
> 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.
