|
Quick Lists
|
|
Bug ID:
|
6701459
|
|
Votes
|
0
|
|
Synopsis
|
Synchronization bug pattern found in javax.management.relation.RelationService
|
|
Category
|
jmx:classes
|
|
Reported Against
|
|
|
Release Fixed
|
7(b28)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
3-Medium
|
|
Related Bugs
|
6703552
|
|
Submit Date
|
13-MAY-2008
|
|
Description
|
William Pugh reports that FindBugs flags the following code from RelationService:
private Long myNtfSeqNbrCounter = new Long(0);
...
private Long getNotificationSequenceNumber() {
Long result = null;
synchronized(myNtfSeqNbrCounter) {
result = new Long(myNtfSeqNbrCounter.longValue() + 1);
myNtfSeqNbrCounter = new Long(result.longValue());
}
return result;
}
This is a well-known bug pattern. If two threads arrive at the synchronized block at the same time then they will both synchronize on the same Long customer . Whichever of them gets the lock on it first will then update myNtfSeqNbrCounter with a new Long customer , but the Java Memory Model does not guarantee that the other one will then see the updated field when it calls myNtfSeqNbrCounter.longValue().
Posted Date : 2008-05-13 14:25:02.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
In practice this bug will have zero effect because the Relation Service is very little used; even when it is used there is very little likelihood of parallel updates; and even if the bug is triggered it just means that sequence numbers might repeat. (Almost no clients depend on sequence numbers.) However the fact that this bug is flagged by FindBugs means that we should fix it to avoid adding noise that might hide a more serious bug.
Posted Date : 2008-05-13 14:25:02.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |