You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel Luo (JIRA)" <ji...@apache.org> on 2009/12/31 08:51:29 UTC
[jira] Created: (DERBY-4497) Incorrect double checked locking idiom
used in VTIResultSet
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
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.
[jira] Commented: (DERBY-4497) Incorrect double checked locking
idiom used in VTIResultSet
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796287#action_12796287 ]
Dag H. Wanvik commented on DERBY-4497:
--------------------------------------
I agree with Knut's analysis of the intention of the synchronization block here. I'm not quite sure how this method is supposed to be used, though..As Knut says, it's in not in use, nor is it's corresponding getSharedState method. Interestingly, in FromVTI.java, the state is not shared (saved in getPreparedStatement().getSavedObjects()), cf. FromVTI#setSharedState. This does not seem to fulfill the interface contract: "Saves an object associated with a key that will be maintained for the lifetime of the statement plan." But this may not be meaningful for FromVTI.
Also, in VTIResultSet#setSharedState, a null value removes the key from the map, but this behavior is not replicated in FromVTI's version.
> 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.
[jira] Updated: (DERBY-4497) Incorrect double checked locking idiom
used in VTIResultSet
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-4497) Incorrect double checked locking
idiom used in VTIResultSet
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795575#action_12795575 ]
Knut Anders Hatlen commented on DERBY-4497:
-------------------------------------------
Here's my understanding of this code:
A VTIResultSet instance is never accessed concurrently by two threads because of higher-level synchronization (on the Connection object). Fields of VTIResultSet will therefore be read by the same thread that updated them, and visibility of changes is guaranteed without more synchronization. So the synchronization in this method is there only to protect the savedObjects array (which may be accessed concurrently by multiple threads if the execution plan is shared between many statements), and I believe there is no double-checked locking in this method.
> 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.
[jira] Resolved: (DERBY-4497) Incorrect double checked locking
idiom used in VTIResultSet
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-4497.
---------------------------------------
Resolution: Invalid
Since there seems to be agreement that this is not a bug, I'm resolving the issue as invalid.
> 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.