-
Bug
-
Resolution: Fixed
-
P4
-
None
-
None
-
b36
-
generic
-
generic
-
Verified
In a multi-threaded environment, when java.util.SimpleTimeZone object is used for a default timezone, there can be a race condition between cloning the defaultTimeZone instance in Timezone.getDefault() method and internal read-only multi-threaded usage of defaultTimeZone instance (obtained internally by package-private Timezone.getDefaultRef() method) which can result in inconsistency of cache that is used to validate a particular time/date in DST.
When a thread is cloning a default timezone object (SimpleTimeZone) and at the same time if a different thread modifies the cache values (cacheYear, cacheStart, cacheEnd), they can be cloned in inconsistent state which leads to incorrect DST determination when the cloned instance is used for calculations.
We considered two approaches to fix the issue.
1)Synchronize access to cloning default timezone object when cache is being modified.
2)Invalidate the cache while returning the clone.
When a thread is cloning a default timezone object (SimpleTimeZone) and at the same time if a different thread modifies the cache values (cacheYear, cacheStart, cacheEnd), they can be cloned in inconsistent state which leads to incorrect DST determination when the cloned instance is used for calculations.
We considered two approaches to fix the issue.
1)Synchronize access to cloning default timezone object when cache is being modified.
2)Invalidate the cache while returning the clone.