I find this in DateDeserializers.java synchronized (_customFormat) {
try {
return _customFormat.parse(str);
} catch (ParseException e) {
return (java.util.Date) ctxt.handleWeirdStringValue(handledType(), str,
"expected format \"%s\"", _formatString);
}
}
Isn't it synchronized here ?
Mohan
On Thursday, 13 October 2016 01:57:15 UTC+5:30, Tatu Saloranta wrote:
>
> On Wed, Oct 12, 2016 at 12:01 AM, Mohan Radhakrishnan <
> radhakris...@gmail.com > wrote:
>
>> First question based on your reply.
>>
>> >>Usage of `DateFormat` itself is synchronized such that this aspect
>> itself is not problematic
>>
>> The code synchronizes 'DateFormat' when mapping data across multiple
>> threads ? Where exactly is this done ?
>>
>
> A new instance is created with a clone; no sharing is done. If you want to
> see where, have a look at code.
>
> -+ Tatu +-
>
>
>>
>>
>>
>> Thanks,
>> Mohan
>>
>> On Wednesday, 12 October 2016 03:07:41 UTC+5:30, Tatu Saloranta wrote:
>>>
>>> It means that `ObjectMapper` is only thread-safe when ALL configuration
>>> is done first, before any usage.
>>> This includes, but is not limited to, configuring default `DateFormat`
>>> to use.
>>> Usage of `DateFormat` itself is synchronized such that this aspect
>>> itself is not problematic, rather, settings of `ObjectMapper` are assumed
>>> to be fixed when first `readValue()` or `writeValue()` is done (*)
>>>
>>> So if you do need to be able to change active default `DateFormat` to
>>> use, you need to either create separate `ObjectMapper`s (inefficient but ok
>>> if you have just couple), or use ObjectReader/ObjectWriter. Latter allow
>>> thread-safe creation of differently configured instances and are designed
>>> for more flexible configuration.
>>>
>>> You can think of `ObjectMapper` as a factory for creating
>>> `ObjectReader`s and `ObjectWriter`s; with couple of convenience methods as
>>> short-cuts.
>>>
>>> I hope this helps,
>>>
>>> -+ Tatu +-
>>>
>>> (*) What happens with any attempted changes after this is undefined, but
>>> is likely one of (1) ignoring new settings, (2) using new settings, (3)
>>> failure in form of exception getting thrown.
>>>
>>>
>>>
>>>
>>> On Tue, Oct 11, 2016 at 3:37 AM, Mohan Radhakrishnan <
>>> radhakris...@gmail.com> wrote:
>>>
Hi,
I see this comment on setDateFormat
If you need per-request configuration, use {@link #writer(DateFormat)}
to * create properly configured {@link ObjectWriter} and use that; this
because * {@link ObjectWriter}s are thread-safe whereas ObjectMapper
itself
is only * thread-safe when configuring methods (such as this one) are NOT
called.
Does this mean that ObjectMapper itself cannot be thread-safe when we
set a date format ?
Does this mean that DateFormat isn't thread-safe ? DateFormat's aren't
thread-safe.
Thanks,
Mohan
--
You received this message because you are subscribed to the Google
Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jackson-user...@googlegroups.com.
To post to this group, send email to jackso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "jackson-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jackson-user...@googlegroups.com .
>> To post to this group, send email to jackso...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jackson-user+unsubscr...@googlegroups.com.
To post to this group, send email to jackson-user@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
