[
https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Pugh updated CODEC-55:
---------------------------
I have no problem changing the name "createThreadSafeCodec" to whatever you
want. I thought codec was safe, since that is in the package name and the
project name. The fact that RefinedSoudex is not a decoder is not important
enough to have a separate package (org.apache.commons.encoders???), so I
figured it was not important enough to stray from consistency.
The problem this is looking to solve is to merge "documentation" of thread
safety with the ability of getting thread safe objects. Having to have
multiple instances of encoder/decoders for different property combinations is
an orthogonal issue to thread safety. This fix just protects the user from
breaking their own thread safety by changing encoding parameters while other
threads are using them. Doing so is just not thread safe (at least not in a
way we can reasonably protect against in codec).
1) You cannot simply use synchronization, for the obvious reasons that two
threads can override their own setting variables (and that it would be
unnecessarily slow)
2) Using ThreadLocal storage for each parameter will cause strange problems in
any case where a codec is handed across threads. This can happen
a) If someone creates a singleton for everyone to use (in the common case
where an app is only using one encoding/combination of properties)
b) If someone is creating a map to manage their own codecs (in the case
that they are worried about this, and have built their own maps (I think this
is definately a possibility for existing code))
c) In an app where there are many worker queues
If you have have a case where you have actively many combinations, I think the
best solution to use thread local storage for each codec/encoder/decoder
itself, and then don't use thread safe ones. This way, you have less TLS
lookups. In actuality, simply allocating/deallocating in these cases is
probably fast enough as well
> make all "business" method implementations of public API thread safe
> ---------------------------------------------------------------------
>
> Key: CODEC-55
> URL: https://issues.apache.org/jira/browse/CODEC-55
> Project: Commons Codec
> Issue Type: Wish
> Reporter: Qingtian Wang
> Attachments: concurrentCodecs.diff, concurrentQDiff.diff,
> urlcodec.patch
>
>
> Maybe most of the implementations are already thread safe. Just such that
> codec can say so in general...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
