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 "Mike Matrigali (JIRA)" <ji...@apache.org> on 2013/07/12 17:23:48 UTC

[jira] [Commented] (DERBY-4478) Use AtomicLong for XactFactory.tranId

    [ https://issues.apache.org/jira/browse/DERBY-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707008#comment-13707008 ] 

Mike Matrigali commented on DERBY-4478:
---------------------------------------

I reviewed this change and it looks ok to me.  I was particularly looking to make sure the change is backward compatible
in the soft upgrade case, but that does not seem to be an issue as we are only changing a private in memory variable. 
The object that is persisted to disk, the "xid", is set with a  real long so we are not changing the disk representation and
those that need to go back to a previous derby release and a lower level jvm should be ok.

For those looking to use Atomic elsewhere should look closely at the javadoc, they are not 1-1 replacements for associated
base types, ie like long.  For instance:
"Atomic classes are not general purpose replacements for java.lang.Integer and related classes. They do not define methods such as hashCode and compareTo. (Because atomic variables are expected to be mutated, they are poor choices for hash table keys.) Additionally, classes are provided only for those types that are commonly useful in intended applications. "
                
> Use AtomicLong for XactFactory.tranId
> -------------------------------------
>
>                 Key: DERBY-4478
>                 URL: https://issues.apache.org/jira/browse/DERBY-4478
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions: 10.6.1.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d4478-1a.diff
>
>
> Dyre Tjeldvoll posted some results on DERBY-3092 that indicated that some types of load might cause contention on XactFactory.tranId (a shared long), and suggested that it was replaced with a java.util.concurrent.atomic.AtomicLong on the platforms that support java.util.concurrent.*.
> I'm splitting this issue out from DERBY-3092 so that the two possible improvements reported there can be addressed independently.

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