• 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

J2EE - Perfomance and scalability issues

 
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
This is regarding the activation and passivation methods in the EJBBean.If you disable these methods does it help to improve on the performance.
I think it should - as the time will not be spent moving the objects in and out of memory.Would like to be corrected, though!!
Thanks in advance.
Regards,
Sandeep

  • Sun Certified Programmer for Java 2 Platform Scored 93 per cent
  • Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java Scored 56 out of 59
  • IBM Enterprise Connectivity with J2EE Scored 72 per cent
  • Enterprise Development on the Oracle Internet Platform Scored 44 out of 56

  • [This message has been edited by Desai Sandeep (edited May 09, 2001).]
 
Ranch Hand
Posts: 1871
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I think activation and passivation infact improve performance. They are specifically there for this reason.
When activation and passivation take place then the bean's state [not the bean] is removed from memory and the bean is put back in a pool [this is in case of entity] so that other clients can make reuse of them.
Let us say if there was no activation and passivation. Then an entity bean that is has not been used my be using resources like having a connection to a database open which is a waste of resources.
I do agree that passivation and activation come at a cost but the cost [ which is the time spent by the cpu passivating and activating ] is very less when compared to tbe benefits.
The same is the case for the stateful session bean
------------------

Mahindrakar
IBM Application Server Forum Moderator
Consultant - Zensar Technologies.
SCJP2 & SCJEA (Part I)

[This message has been edited by Rahul Mahindrakar (edited May 09, 2001).]
 
Desai Sandeep
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mahindrakar,
Thank you for the response.
I have been reading Mastering Enterprise JavaBeans by Ed Roman time and again to come up with a solution to the subject.
All my readings suggest that activation and passivation primarily takes care of managing the memory requirements.And this is what you have also mentioned.Definitely, releasing memory resources would give better performance.But we need to consider in the light of how this is done and at what expense.
Reading the following piece of information - EJB Design Stategies-Partitioning Your Resources-Page 189 in Ed Roman's book makes me rethink on this issue.


Because acquiring and releasing resources may be costly operations, categorizing your resources as outlined is a vital step that you must take.Of course, the most stingy way to handle resources is to acquire them on a just-in-time basis and release then directly after use.For example, you could acquire a database connection only when you're about to use it and release it when you are done.Then there would be no resources to acquire/release during activation/passivation.In that case, you'd let the container pool your resources and thus manage the resources for you.The disadvantage to that is you need to code resource requests/releases over and over again in your bean code.


Clearly Ed Roman, wants to suggest an alternative for activation/passivation.
I normally use activation/passivation to store/retrieve objects in temporary storage and the DB apart from releasing Connection objects.
Keeping this in view, the following could be very costly operations

  1. Serialize the Object in the File and retrieve it for later use (IO operations may always be costly)
  2. Want to connect to the DB tier to store the objects, especially in Session Beans.In Entity Beans, ofcourse this is done automatically by calling ejbLoad()/ejbStore() atleast once.This involves dependency over the networks, which may always hamper performance

  3. Also, calling these methods are at the discretion of the Container.If the Container calls it on a regular basis, I think it would be a performance hit.In that case, as Ed Roman suggests adding more code and taking care of activation/passivation on "need-based" basis may be a better option - Probably providing higher memory requirements and not depending on activation/passivation may give better performance!!
    Please let me know your views on this.
    Regards,
    Sandeep

    • Sun Certified Programmer for Java 2 Platform Scored 93 per cent
    • Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java Scored 56 out of 59
    • IBM Enterprise Connectivity with J2EE Scored 72 per cent
    • Enterprise Development on the Oracle Internet Platform Scored 44 out of 56

    • [This message has been edited by Desai Sandeep (edited May 09, 2001).]
 
Rahul Mahindrakar
Ranch Hand
Posts: 1871
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Because acquiring and releasing resources may be costly operations, categorizing your resources as outlined is a vital step that you must take.Of course, the most stingy way to handle resources is to acquire them on a just-in-time basis and release then directly after use.


I believe that ed Roman is write. But we have to take whatever others say with a pinch of salt.
Let say i have a statelless session bean and all the methods access the database. if i do what ed Roman says i am doing an inefficent thing. I have to acquire resource each and every time a method is invoked. Your code gets bloated and also the bean is inefficent. So what do you do. You put obtaining and releasing the connection in the Activation/Passivation.
On the other hand lets say i have a statelless session bean and only One of the methods access the database. if i do what ed Roman says i am doing an efficent thing. I have to acquire resource each and every time the specific method is invoked. Thus Resource are available for others to use.

------------------

Mahindrakar
IBM Application Server Forum Moderator
Consultant - Zensar Technologies.
SCJP2 & SCJEA (Part I)
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

hi ,
Actually I am very much new to the ejb around 6 months old.
I want to share view regarding activation and passivation.It think it will definitaly increase the performance.But it depends the type of the bean.
We can consider two cases as one is entity bean

In any system thousands of records are presnt for one bean and that thousands of instances are there which going to serve the ejb objects.So it managable to the application server only when it can able to activate and passivate the bean instances.
Now for stateles bean it not that much important to be activate and passivate...because same instance can be assigned to different ejbobjets.
But for stateful session bean the activation and passivation mechanism is very expensive because it going to store the transition state.
So as per my conclusion it depends on the type of bean.
If i am misteaken some where please forgive me



 
Desai Sandeep
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mahindrakar,
Considering the responsibilities, defined for Session Beans (as a client view in the Application Server) and Entity Beans (as representing Business Data in the DB, doing all the DB interactions), can we say that Ed Roman is correct - Activation and Passivation disabled, we will get a better performance.
Looking forward for your views, so that we can pin this one down.
-- Sandeep.

[This message has been edited by Desai Sandeep (edited May 11, 2001).]
 
Desai Sandeep
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ankur,
Thank you for responding to my post.It helps a lot to get the views of most people, instead of depending on your own knowledge.


In any system thousands of records are presnt for one bean and that thousands of instances are there which going to serve the ejb objects.So it managable to the application server only when it can able to activate and passivate the bean instances.


I agree to your view point.However, the only thing that we need to consider is making those 1000's of EJBObject passive and then active will take a hell lot of time and resources by the server.So there are trade-offs between the two - keeping it active and consuming memory resources, and activating and passivating it - Which is better from performance view-point, is something we need to think about!!


Now for stateles bean it not that much important to be activate and passivate...because same instance can be assigned to different ejbobjets.
But for stateful session bean the activation and passivation mechanism is very expensive because it going to store the transition state.


That is absolutely correct.However, for Stateful Beans activation/passivation mechanism would not be as expensive as the EntityBeans, going by the instances present in the Application Server.I presume, at any given time, you would have more Entity Bean instances compared to Session Bean instances in the Application Server - although it depends on the implementation of the Application Server by the Vendor.
-- Sandeep
 
reply
    Bookmark Topic Watch Topic
  • New Topic