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.
cheers
Kasper
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
