jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bulent Erdemir" <bule...@gmail.com>
Subject Re: JCS performance in multi-threaded environments
Date Mon, 12 Nov 2007 21:41:21 GMT
Krishnan, are you sure batch updates are propagated in an asynchronous
manner ? I'm looking at RemoteCache.update() and all I see is, for
every object to be updated:
remote.update( serialized, getListenerId() ); is called on
RemoteCacheServer. I didn't go through clustered cache source a lot,
however, from what I can see, every put (update) is propagated using
RMI. There's a property on IRemoteCacheServerAttributes, though, which
is localClusterConsistency. The description says, "should cluster
updates be propagated to the locals". So, if set, cluster updates
should be propagated to local caches. In an online mannger . I've read
your other thread, and I don't understand why your put's don't get
replicated to clustered caches. If your measurements are correct, then
we should wait for an answer from the JCS author.

Jeremy, I'm looking at IMemoryCache implementations and I haven't seen
any reference to Doug Lea's ConcurrentHashMap. In fact
AbstractMemoryCache constructor reads as:
    /**
     * Constructor for the LRUMemoryCache object
     */
    public AbstractMemoryCache()
    {
        status = CacheConstants.STATUS_ERROR;
        map = new Hashtable();
    }

Internal map is a regular HashTable. Could you point me to a location
in the source where ConcurrentHashMap is used ? Besides, cache locking
is done around of the map's put methods. So, even if map was a
ConcurrentHashMap, it would lock internally around segments, and
wouldn't be of any help because the whole cache region would have been
locked prior to the map's method execution.

Bulent Erdemir

On Nov 12, 2007 5:20 PM, Cooper, Jeremy
<jeremy.cooper@retirementpartner.com> wrote:
> JCS uses the ConcurrentHashMap,  only it uses Doug Lee's version rather
> that the version that ships with jdk 1.5+.  The version of
> ConcurrentHashMap in the jdk is based on Doug Lee's version.
>
> Thanks
> Jeremy
>
>
> -----Original Message-----
> From: Bulent Erdemir [mailto:bulente@gmail.com]
> Sent: Sunday, November 11, 2007 1:00 PM
> To: jcs-users@jakarta.apache.org
> Subject: JCS performance in multi-threaded environments
>
> Hi,
>
> I've been reading the source code of both EHCache and JCS to find out
> which one to use in my project.
>
> I found that, EHCache locks the entire cache (via synchronizing on the
> Cache in a get() call. In this synchronized block the code checks both
> the memory map and the disk map, along with all the management and
> logging code.
>
> JCS, on the other hand, only synchronizes on the memory cache's get()
> call of the region, excluding the management code (updating counters,
> logging, etc.). In other words, the job done in the synchronized block
> is less than the one in EHCache, hence more suitable for
> multi-threaded, concurrent access environments.
>
> This is enough evidence for me to conclude that JCS is better for my
> project.
>
> However, I would like to ask the authors of JCS why they ever use
> locking of an entire region at all. I've been looking at the
> ConcurrentHashMap source of the JDK 6, and saw that they have two nice
> features:
> 1) The map is divided into segments which allow for partial locking of
> the entire map. This way, during concurrent access, all the map is not
> locked, even for brief moments, but portions of it.
> 2) The locking is done only for a very brief amount of time, during
> access to the value of the stored element. No management overhead.
> This is acceptable.
>
> I think both features above are essential for a caching system.
> Currently, the whole region is locked during every get (although the
> implementation is better than EHCache). No segments, longer locking
> duration compared to ConcurrentHashMap.
>
> I wonder why JCS authors did not implement these ideas. Am I missing
> something ?
>
> Regards,
> Bulent Erdemir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-users-help@jakarta.apache.org
>
>
>
> The information contained in this message and any accompanying attachments may contain
privileged, private and/or confidential information protected by state and federal law.  Penalties
may be assessed for unauthorized use and/or disclosure.  This message and any attachments
are intended for the designated recipient only.  If you have received this information in
error, please notify the sender immediately and return or destroy the information.
>
> This e-mail transmission and any attachments are believed to have been sent free of any
virus or other defect that might affect any computer system into which it is received and
opened. It is, however, the recipient's responsibility to ensure that the e-mail transmission
and any attachments are virus free, and the sender accepts no responsibility for any damage
that may in any way arise from their use.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-users-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org


Mime
View raw message