Well, the memory problem could also be solved by removing the buffers (bufferB byte[128] and bufferC char[128]) from Encoding_OneByte.

None of the classes in the hierarchy have a constructor, so the only overhead is standard object creation. So the question is if Concurrent.synchronizedMap's get() is more expensive than creation.
Since there is no difference between the objects, there is no need to synchronize the whole function. If N threads all race to create a Cp1252 object, it matters not a bit which one ultimately puts in in the Map.
Heck, then you could use Class.forName to create the encoder, and no one would need to maintain that huge switch statement.

BTW, I don't have CVS access, I was using Koders.com to look at the code.

-----Original Message-----
From: Firebird-Java@yahoogroups.com [mailto:Firebird-Java@yahoogroups.com] On Behalf Of Roman Rokytskyy
Sent: Monday, June 05, 2006 3:13 PM
To: Firebird-Java@yahoogroups.com
Subject: Re: [Firebird-Java] Possible memory leak in EncodingFactory ?

Hi,

> Encoding_OneByte would have to be changed, probably for the better.
> Buffers are created that would be stepped on in a multithreaded
> environment, and they aren't needed. The method
> encodeToCharset(String) should be doing the work in the result buffer
> that's created, and
> decodeFromCharset(byte[]) should just create one on the stack.

Sorry for not replying with more precise information, but I remember that there was an attempt to add caching to the EncodingFactory, but the price for it was either instable or slow work in multithreaded env. and the fix was rolled back.

Please check the CVS history for more details.

Roman



------------------------ Yahoo! Groups Sponsor --------------------~--> Everything you need is one click away.  Make Yahoo! your home page now.
http://us.click.yahoo.com/AHchtC/4FxNAA/yQLSAA/saFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links