[
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
