Gregory,
sorry for the short answer in this reply (more on this subject later), but please have
a look at bug 1609, as part of which a much improved version of
TimeLimited is supplied. Let me (and Stein) know what you think of it.
Werner
On Fri, 27 Aug 2004 12:41:10 +0100, 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.)
>
>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
