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]
