the pooled state has different means for different types of beans.
- Stateless session beans cannot be passivate but they can stay on the pool
waiting for the EJB server select him to respond a request
- Stateful session beans are passivate to preserve resources, but he did not go to the pool, he is passivated, he is stored. Stateful session beans do not stay on the pool (you can see this on page 77 of the specification).
- Entity beans are activate when they leave the pooled state and go to the ready state and they are PASSIVATE when go back, but in this case the bean is in the pooled state. Entity beans are passivate when they leave the
ready state and go to the pooled state (page 168 of the specification)
- MDB�s cannot be passivated or activated, they only exists, respond requests on the ready state or does not exist. (page 319 of the specification)
I hope this can help you, I indicate you to study the life cycles of the beans, look at the specification.
Let me put the concept in layman terms.
Let us take example of software industry. There are Programmers and analysts and domain experts.
Programmers - Good with programming languages.
Analyst / Domain Experts - Good in domain knowledge and aware about programming concepts.
Stateless Session beans -
These beans are more of like Programmers. Programmers code for some specific project. Once the project is done, they can work on any other project. The domain the project is based on is not important for Programmers. The programmers mostly deal with programming related problems. (That is why we have bench time) If programmer is not allotted to a project, he/she will be on bench. The project that is looking for more programmers will hire one from the bench.
Notice here that the domain related understanding is not important. Secondly programmer is ready to work on any project that involves programming.
MAPPING THIS CONCEPT TO STATELESS SESSION BEAN
1. Stateless session bean are not bound to one client (Project does not matter if it requires programming services.)
2. Stateless session bean does not store the state. (No need to remember domain related details from past projects. New project with new domain is still ok)
3. Created by app server and are kept in pool. (Programmers are on bench. Who ever needs one will pick from the bench)
4. All stateless session beans created by same Home will always return true to isIdentical test (Does not matter who the programmer is, for all PMs, programmer is just a resource in msp )
Stateful Session Beans -
The Analyst and Domain experts are important and core people in any project. These people are involved for short durations, but the knowledge shared by these people is very crucial for project.
These guys are not always involved in project, but they are mostly allotted to project. These guys will not be pushed on bench, as they are not required for 1 to 2 month. They will only stop actively getting involved in day-to-day activities. But if there is a requirement or design level problem, then the project team calls for domain expert�s help.
So to put is in a simple way, these guys (domain experts no hard feeling here ok ) are mostly sleeping, and when there is a problem, PM goes to them and wakes them up.
MAPPING THIS CONCEPT TO STATEFUL SESSION BEAN
1. Are bound to one client (Domain expert work on one project)
2. Store state for client (Has domain knowledge that is required by project)
3. No pooling but it is simulated through passivation (sleeping) and activation (waking up). (When no work then domain expert goes back to his/her cubicle and takes a nap or read Dilbert. If there is a requirement to provide domain related services then PM goes and asks him/her to wakeup)
4. Statefull session beans might return true or false to isIdentical test.
I guess this shall explain most of pooling and passivation/activation concepts.
Guys correct me if I am wrong
Thank you for your answers ! What is great support here!!
I got the point completly...Statefull beans may be pooled and never be passivated.....Stateful beans can be passivated but not pooled....and I understand the reasons behind that completly too.
Actully I'm going through HFEJB and while posting that que I was in chaper 3...but today I completed chapter 4 and 5 and I completly understand the stuff!!!
Anyways thanks ! Next on I shall keep patience ...but you have been great.!!!
I just realized that my study guide is not totally clear about the descriptions of ejbActivate() and ejbPassivate().
The 2.1 specifications says the following on page 76:
To efficiently manage the size of its working set, a session bean container may need to temporarily transfer the state of an idle stateful session bean instance to some form of secondary storage. The transfer from the working set to secondary storage is called instance passivation. The transfer back is called activation.
A container may only passivate a stateful session bean instance when the instance is not in a transaction.
It's important to understand this concept as the exam page at http://www.sun.com/training/catalog/courses/CX-310-051.xml indicates the following objective on section 5:
State the benefits of Passivation in an EJB container
p.s. Please note that the objectives page is an xml page and not an html one :roll: