Ya know. Just to put this in a little perspective.
These objects are pretty small (QCodec has only two members in it), and
have practically no instantiation cost. Instantiating these and quickly
throwing them out is probably not such a bad idea, and may give you
better performance that doing anything with ThreadLocal. Java VMs are
fairly well tuned for dealing with short-lived, small objects (which
these are).
I can't imagine that many people are using thousands of these per
request, probably, more on the order of one or two a request?
--Will
James Carman wrote:
Try using a ThreadLocal variable to store your Encoder/Decoder that
you need to be thread safe.
On 10/8/07, sebb <[EMAIL PROTECTED]> wrote:
On 08/10/2007, Will Pugh <[EMAIL PROTECTED]> wrote:
David J. Biesack wrote:
Date: Mon, 8 Oct 2007 17:01:02 +0200
From: =?iso-8859-1?Q?J=F6rg_Schaible?= <[EMAIL PROTECTED]>
The java.util.concurrent backport
http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
kind of use.
I know this, but I doubt that we wanna start to depend Apache common components
on it ;-)
Agreed; I, like you, was merely suggesting to what Commons consumers might do
to deal with non-threadsafe codecs.
Might seem like a silly question, but has anyone found anything that
looks like a threading issue in Codec?
Yes - QCodec has a public method that sets an instance variable (see
my comments on CODEC-55).
The code is pretty simple. I did a quick look through the code, and it
seemed like everything was pretty thread safe. It looks like you should
be O.K. as long as:
1) You don't change the parameters to a codec while it's running,
e.g. changing charsets, etc.
See above.
Having said that, I think it would not be too difficult to fix the
classes so that they are thread-safe. Most of the ones I looked at
could even be made invariant.
So their thread-safety would only depend on any external calls they
made; this could presumably be fixed by providing synchronised
versions as suggested earlier.
2) You should not use a MessageDigest returned by DigestUtils by
multiple threads. This should be clear given the API (it's a SUN api)
It also seems to me that the difference between code that you can trust
as being thread safe, and code you cannot trust as being thread safe has
a lot to do with whether it is tested for thread safety. Seems to me
like another way of helping out here would be to build concurrency tests
for whichever APIs you are interested using on multiple threads. Not
sure where we would put them yet, but seems like the only way to assure
thread-safety (especially if we could get someone to volunteer running
them on a big beefy multi-proc machine :).
Indeed.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
