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.)
On 18 Aug 2004, at 15:01, Kalpesh Patel wrote:
Hi All,
I am having a metadata Table and I am running the same OQL query on the
table in a multithreaded environment. But at the time when I am iterating
over the Queryresults the code becomes serial in nature and only one thread
is executiung at that time.
Upon analyzing I found that even if in the mapping the acessmode is
"read-only", In LockEngine.java in load() method we are doing
lock = typeInfo.acquire( oid, tx, action, timeout );
and
if ( lock != null ) lock.confirm( tx, succeed ); (in the finally block)
�
This makes the code serial in nature and the performance of the application
suffers. Am I missing something?
Is there a way of avoiding this locking?
�
-Kalpesh
If the General does not believe that he can win the war,then it does not matter if his army is the world's best.
Kalpesh Patel Sr. Software Engineer CIStems (Software) Limited
[EMAIL PROTECTED] IM: [EMAIL PROTECTED]
tel: mobile: 091-0141-2771716 9829206149
Signature powered by Plaxo Want a signature like this?
Add me to your address book... � ----------------------------------------------------------- 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
