And, a simple map would suffice in that case (lazy-initialized of course). If you need QCodec, then you'd have in incorporate the encodeBlanks and the charset into the map's key (if you really have cases where you do/do not want to encode blanks).
On 10/8/07, sebb <[EMAIL PROTECTED]> wrote: > Which methods do you actually need? > > If you only need BCodec, then that (and Base64 which it calls) look to > be thread-safe, so you only need to instantiate it once for each > different charset. > > On 08/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote: > > The SLA of the project I am working on is 2000 transactions per > > second. And I need to decode a 1K string on each request..... > > > > -Q > > > > > > > > On 10/8/07, Will Pugh <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > > > --------------------------------------------------------------------- > > 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]
