Re: DO NOT REPLY [Bug 50265] FormatDateSupport.dateFormatCache lazy init is not safe
The caching change for #32311 has never been released. I'd like to suggest we revert that change and go back
to creating formatters as needed (as we did in the last release). Due to the removal of synchronized on
Calendar#getInstance() this will solve the original issue and not add any threading issues. If we want to
improve the performance we can do that later by caching formatters in each tag instance, or by using a
thread-safe date/time library uch as Joda.
Thoughts?
Jeremy
On Jan 1, 2011, at 12:18 PM, bugzilla <at> apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50265
>
> Jeremy Boynes <jboynes <at> apache.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Depends on| |32311
>
> --- Comment #1 from Jeremy Boynes <jboynes <at> apache.org> 2011-01-01 15:18:25 EST ---
> The caching was added to resolve 32311, which was opened due to contention
> issues with DateFormat.getTimeInstance() calling Calendar.getInstance() which
> was synchronized. However, the synchronized keyword was removed with Java 1.4
> so this should no longer be an issue for us.
>
> #32311 also notes that the calls to format() on the cached formatters are not
> thread safe and need to be synchronized; this is missing from the current
> implementation. However, in many applications the date/time patterns and Locale
> are likely to be the same and the cache only holds one instance of the
> formatter. By synchronizing on it we will introduce a contention point just
(Continue reading)
RSS Feed