commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: codec - thread safe
Date Mon, 08 Oct 2007 14:23:59 GMT
David J. Biesack wrote on Monday, October 08, 2007 3:02 PM:

>> Date: Sat, 6 Oct 2007 23:31:19 -0500
>> From: "Qingtian Wang" <qingtian.wang@gmail.com>
>> 
>> Well, it's pick-your-poison kind of a deal. Either block on one
>> instance and take a performance hit, or burn up the memory with lots
>> of instances.....
> 
> Why not compromise? Create a ThreadPoolExecutor of some
> reasonable size and submit a FutureTask
> to run the encode or decode, and then do a future.get() when
> the value is needed. You might
> even get some concurrency if you can start the encode, then continue
> doing other work until you need the result.

Because it runs on JDK 1.3? However, that's the reason why I argumented not to promise thread-safety
for any codec and provide synchronization wrappers or a user might take the pool approach
... which is quite easy with JDK 5 as you've provided here :)

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message