[cal10n-dev] MessageConveyor caching

[Rick Beton]

Hi all,

It occurred to me that there is a performance penalty for loading
MessageConveyor instances which can be mitigated with an extra cache like
this

public class MessageConveyor implements IMessageConveyor {
    private static final Map<Locale, MessageConveyor> INSTANCES = new
ConcurrentHashMap<Locale, MessageConveyor>();

    private final Locale locale;
    final Map<String, CAL10NResourceBundle> cache = new
ConcurrentHashMap<String, CAL10NResourceBundle>();

    /**
     * Constructs an instance with a {@link Locale} associated with this
     * instance.
     *
     * @param locale
     *            required locale
     */
    MessageConveyor(Locale locale) {
        this.locale = locale;
    }

    /**
     * Gets a cached instance associated with a particular {@link Locale}.
If
     * the time taken to read the resource files is significant, the cached
     * instances will perform significantly better than simply creating a
new
     * instance whenever it is needed.
     *
     * @param locale
     *            required locale
     */
    public static MessageConveyor get(Locale locale) {
        MessageConveyor instance = INSTANCES.get(locale);
        if (instance == null) {
            instance = new MessageConveyor(locale);
            INSTANCES.put(locale, instance);
        }
        return instance;
    }
...
}

Note that the constructor is now package-private - this breaks the API so
will need to be agreed. It is not strictly necessary but desirable to
encourage the most efficient use of Cal10n.

The internal cache (called 'cache') holds the actual resource bundles and
avoids them being repeatedly read from disk.  Previously, this cache would
be dropped every time an instance was no longer referenced. The next time
the same locale was required, a new instance would be needed, also needing
the same files to be read from disk again.

Now, the new static INSTANCES cache holds the instances, each of which holds
its cache containing the resource bundles that were read from disk.  There
is a small penalty in consulting the INSTANCES cache but this should be no
worse than re-reading the files (and probably much better).

I've attached a patch, which replaces the one I sent on the 14th.

Regards,
Rick
-- 
Big Bee Consultants Limited : Registered in England & Wales No. 6397941
Registered Office: 71 The Hundred, Romsey, Hampshire, SO51 8BZ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/cal10n-dev/attachments/20100316/32fc3657/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rick2.patch
Type: text/x-patch
Size: 15706 bytes
Desc: not available
URL: <http://qos.ch/pipermail/cal10n-dev/attachments/20100316/32fc3657/attachment-0001.bin>