We are using JCS in heavily multi-threaded applications. I've not noticed any performance bottlenecks due to synchronization.
On Wed, 2008-05-21 at 08:22 -0700, Tim Cronin wrote: > you might want to check again. > > JCS requires the use of a concurrent library, > > and also allows distributed caching. > > > > -----Original Message----- > From: Kasper Nielsen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 20, 2008 4:58 PM > To: JCS Users List > Subject: Re: Does JCS use multi-threading? > > 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
