• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

No of bean instances in pool

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi all..
i've small problem.I m learning J2EE and the appserver i m using is Websphere Application Server V 4.0. The problem is I've made a simple stateful session bean and i want to fix the no. of beans in the pool to say 3 or 4. But i dont know how to do that in WebSphere Applicaion Server. I've explored both the Admin console as well as the Application Assembly Tool but was not able to find it.
please help
Thanx in advance
gaurav
 
Ranch Hand
Posts: 217
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is not in the admin console, in stead it is supposed to be in the admin.config file.
You must have WAS4.0 with FP2(up) to have this feature. Following is the information provided by an IBM EJB container architect:
On a related topic, allow me to explain in a little more detail what the various settings are doing within the EJB container.
First, the "ejb cache size" setting that is available from the application server properties page in the SM console is not the maximum number of beans that can be hosted in the app server. It is just the number of "buckets" in a hash table that is used to keep track of the number of active beans. For best performance, you should set the number of buckets in the table to somewhere around the maximum number of active beans that you expect to have during normal use. (You can use the WebSphere resource analyzer to measure this in your actual situation.) This is because hashtables perform best when the number of elements per "bucket" is minimized (ideally each bucket should have no more than one element). Thus, setting the ejbCache size value is mainly a performance tuning adjustment and is not an absolute limit on the number of active instances.
The other aspect of this is the ability to set the number of available bean instances in the instance pool for each bean type. The default values for these pools are a lower bound of 50 and an upper bound of 500. This means basically that as after a bean is passivated and becomes available for returning to the instance pool, it will be put in the pool. Once there are over 50 beans in the pool, a background thread starts to run which slowly drains the pool back down to 50 beans. If instance are returned to the pool so rapidly that the number of instances in the pool exceeds 500, any instances attempted to put back in the pool will be let go for garbage collection rather than being put back into the pool. This will continue until the number of instances in the pool goes below 500.
Like I said, these are the default values and until version 4.0.2, they were not modifiable. However, 4.0.2 added the capability to adjust these min and max values either for all bean types, for specific bean types, or any combination of both. This adjustment is done via system properties that can be set on an appserver-by-appserver basis in the system management console.
Documentation on how to use this function appears in the 4.0.2 Release Notes, under the heading "Setting EJB Container pool sizes".
------------------------------------------------
Unfortunately, I couldn't get this setting work for Stateful SessionBean(haven't had time to verify it on 4.0.3). So you can switch back to specify the maxium bean in EJB container(click the Service for your JVM/AppServer, find EJB Container service), that will limite SFSB's instance number...But in your case, you may have to deploy your SFSB into a seperate EJB container, your given number is just too small.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic