Bruce, Thats fine that we will change the Cache implementation but if you see my mail was not regarding the Cache performance.
My real Question is that if accessmode is "read-only" in mapping.xml then why we are doing this locking business after fectching the object from cache. Its OK to do this locking business in accessmode="shared" or "exclusive" as we will either upgrade or waitforconfirmation or maintain a linkedlist of readonly locks. But does it makes sense to maintain this linkedlist of readonly locks if we know in advance that we are just going to do read operations? The real problem is that code becomes serial, if all I was doing was fetching the same object in different Transactions, in multiple threads. -Kalpesh -----Original Message----- From: Bruce Snyder [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 9:25 AM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] In Multithreaded environment Why acquire a lock when accessMode is "read-only" Gregory Block wrote: > It would be nice if we included the oswego concurrency library and moved > to ReadWriteLock API for operations like this. > > Also, sidenote: I've just done some perf analysis on our staging server > and found some pretty hefty inefficiencies in the TimeLimited cache. > (We use a low 10sec cache on some; larger on others) > > - TickThread is reported as using an awful lot of CPU; > - It seems to spend that time iterating. > - Iterating through hashtables is a bad thing in general. > > So, I've got two suggestions. > > 1) Move to ehcache implementation for our caches; it's a > high-performance cache, and it's pretty good at this kind of stuff. > Introduces a jar, but I'd almost rather have another jar than our > current implementation... > > or 2) I can provide a hacked up version of a conveyor belt > implementation of TimeLimited; we've got a conveyor belt API which > should be 1.2/1.3 compatible which we've hacked on just for the purposes > of getting a good performance out of large collections of time-limited > objects. Basically, the conveyor belt contains n containers; items > always go into the first container on the belt. Timer events go off > every (cache-time/buckets); when the timer event goes off, everything > moves over by one; a new bucket goes on to the front of the conveyor > belt, where new objects go, and one drops off the end, > which goes to a destructor and then to the garbage collector to gc. > When you ask for something out of the cache, you ask all the buckets on > the belt; > when something goes in, you verify that it isn't already in one of those > buckets. > > It's quick, it's painless, it's low-cpu, and it makes disposal nearly > free. On the other hand, your time granularity isn't "exactly" n - it's > n to the nearest timer event. It's close, though. > > Someone can decide whether to do 1, 2, or leave it the way it is. (I'd > prefer *not* to leave it the way it is.) Gregory, I would prefer the Oswego util.concurrent libarary. Yes, it is another third party dependency but only prior to J2SE 1.5. It's actually integrated into J2SE 5.0. We can get around this via the Ant build (e.g. J2SE < 5.0 uses the Oswego util.concurrent library whereas J2SE => 5.0 uses the java.util.concurrent libarary (unless there are clashes with old and new)) quite easily. Ultimately, our goal is to provide a JCache (http://www.jcp.org/en/jsr/detail?id=107) compliant cache API. I would be in favor of offering your solution two above as a configurable option to Castor users via the castor.properties file. All we need to do is give it a unique name. Bruce -- perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");' The Castor Project http://www.castor.org/ Apache Geronimo http://incubator.apache.org/projects/geronimo.html ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
