jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasper Nielsen <n...@kav.dk>
Subject Re: Does JCS use multi-threading?
Date Tue, 20 May 2008 21:57:41 GMT
Debasis Bhattacharyya wrote:
> As I see, some time JCS memory cache is slower than expected. I am comparing with my
hand-coded memory cache using hashMap. JCS is much slower than the other one. This trade off
is compensated by features like shrinking, expiry etc, I believe. Now, question here is will
JCS be faster in an multi-processor server? It can be faster if it uses multi-threading internally
to do jobs like cleaning, expiry etc. 
>   I thought of asking the community before checking the code. Any comment?
>   Thansk in advance.

I'm not sure I fully understand your question. But if what you are 
asking is somewhat along the lines of "does JCS allow concurrent access 
to its entries as in, for example, ConcurrentHashMap".
If that's the question the answer is no. Actually I don't think they are 
any Java-based cache solutions that allow concurrent access, at least 
not in the open source business. The main reason being that you need one 
big fat lock for your replacement policy (whether it being LRU, LFU, 
ect...). There are certain variants of the CLOCK algorithm that allow 
for concurrent access. And perhaps you could implement a concurrent 
queue that supports faster removal then ConcurrentLinkedQueue. In which 
case you could implement a LRU solution. But if you take a look at the 
sourcecode for ConcurrentHashMap, which only supports a small subset of 
the functionality of say JCS, you quickly realize how big a task it 
would be to implement something like that.
There are certain other concurrency tricks you can play but haven't seen 
them in any open source libraries.


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

View raw message