Re-2: Proposal for Jonas Container Improvement

[markus . karg]

Title: RE: Proposal for Jonas Container Improvement

[Markus Karg] But what if there is a transaction running that uses lots of beans? I mean, maybe I understand not in full what your solution would be, but at the moment, JOnAS can hold, let's say a number of 10000 instances on my machine. Then the memory is exceeded. If there is additional caching, JOnAS needs additional space for that caching. But now it does not have some. So if we increase cache, this would lead to JOnAS can hold only less instances, why with fixed cache maximum, it could hold more instances, but could not cache them. This means, stability would be higher, but performance would be decreased.     Original Message        processed by Tobit InfoCenter  Subject:  RE: Proposal for Jonas Container Improvement (21-Aug-2001 22:11) From:     [EMAIL PROTECTED] To:       [EMAIL PROTECTED] (and 3 other)   This occurs only if more instances are in use than the cache size so there are no old values to push out, you have to increase the cache.   -----Original Message----- From: Markus Karg [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 3:00 PM To: Halas, Miroslav; 'Philippe Durieux'; jonas-users Subject: Re: Proposal for Jonas Container Improvement   [Halas, Miroslav] Just one comment. Please avoid pitfall which was present in Weblogic (I think 4.5.1). The poolmax is just suggested value, but you have to be able to actually create and manage more instances than specified by poolmax. Example where it happens is when you run a finder which returns more values than poolmax. There was a bug in Weblogic where WLGC increased the size of the cache but still threw an exception that the size is full.   [Markus Karg] So what do you suggest? Should we increase the cache, or should we push old values out of the cache?         if already mapped -> OK         else if instance in the pool: get it and read state.         else if count < poolmax: create a new one and read state.         else clean instances not used to decrease count              and then, create a new one... [Halas, Miroslav] This will be an interesting problem because we would like to release those instances which are not used often so there will need to be some either usage count, last used time, round robin like mechanism [Markus Karg] The problem is to find a strategy that will fit most use cases. Are newer entries better than often used? Hm... Maybe a combination would be best? But this will lead to complex computations what will have impact on performance. And the question is, if this really would be a problem at all, I mean, at the moment, we have no cache at all... What would you suggest? A property? Pluggable Cache Managers? [Halas, Miroslav] I can almost guarantee that this should increase performance f our application, it will be interesting to see how effective it will be. [Markus Karg] The benefit is use-case dependent. We have one application that acts like a file explorer, and it uses just similar mechanism. It has a dynamic cache and uses block-prefetching of five rows a time. This made that thing running fluently, where it formery needed half a minute to scroll. This is the upper bound. The lower bound is an application we have, that just loads a bean, lets the user edit, and saves back. There is no benefit at all. So I think there is no general rule how it will perform in the specific application. But nevertheless, I think the overall performance of JOnAS would be increased dramatically, what will lead to more transaction per second, so one machine can handle more clients. To: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]