• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Stateless Session Beans for Scalability

 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have an application that is a fairly straightforward Struts project where the Action classes call some business methods on plain old java objects (POJOs), stuff the results into the request, and forward to JSPs for display.

We are expecting a significant increase in traffic after our next release. The POJOs are short-lived, but we could conceivably reach the point where we run out of memory.

My thought is to either turn the POJOs into Stateless Session Beans or have Stateless Session Beans control access to the POJOs. We could then tune performance by adjusting the pool size of the Stateless Session Beans. In essence, the Stateless Session Beans would act as a throttle when we reach a certain level of traffic.

The application has no need for other kinds of EJBs.

We are already using a full J2EE app server for this app, so cost is not an issue.

Any comments / suggestions?

Also, are there any standard metrics for determing pool sizes?

thanks!
[ May 19, 2005: Message edited by: Paul Croarkin ]
 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

...have Stateless Session Beans control access to the POJOs.


This won't solve your problem since you may still end up having many POJOs.

Replacing POJOs by stateless session bean seems to be a viable solution since you take advantages of the container to control/reuse resources.
 
Ranch Hand
Posts: 250
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

###################################################################
I have an application that is a fairly straightforward Struts project where the Action classes call some business methods on plain old java objects (POJOs), stuff the results into the request, and forward to JSPs for display

###################################################################

The approach that you are using currently will have a good response time. I don't know that in your java classes are you making a hit to the database or not and if yes then how you are controlling the transactions.

Also after a flow is over you can null the references of the POJO so that they will be garbage collected.

By implementing the session bean you can make use of the transaction support of the container but as far the memory is concerned implementing session beans won't do much help.

sawan
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic