jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject Re: JCS performance in multi-threaded environments
Date Tue, 27 Nov 2007 03:06:47 GMT
About concurrent hash map:  JCS does not use it in any
of the supplied memory auxiliaries.  The LRU (least
recently used) memory auxiliary has to implement a LRU
eviction policy.  To do this, it has to keep track of
the usage of the various items.  This is done via a
double-linked list that sits on top of a map.  Since
the list needs to be locked along with the map, the
concurrent hashmap wouldn't buy us anything.  

The version of the LRUMap used in JCS is limited, but
faster for basic operations than any other
implementation that I know of.  This is not to say
that something better couldn't be written.  I'm sure
it can.

You are, of course, free to experiment with new
implementations.  Remember, JCS is completely
pluggable.  The memory cache interface is easy to
implement.  Try making your own version.  Test it out
and send it to the list.

Cheers,

Aaron



--- Bulent Erdemir <bulente@gmail.com> wrote:

> 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
> 
> 


---------------------------------------------------------------------
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