Sankar Subbiramaniam

Ranch Hand
+ Follow
since Oct 03, 2000
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sankar Subbiramaniam

Thanks. But I couldn't find the statement in the link you mentioned. Could you please send the link to this statement?
Thanks again.
16 years ago
JSF
Hello,
We want to develop JSF1.2 based application in servlet 2.4 container. Is it possible?
I know that JSF1.2 mandates JSP2.1 container. However we are using facelets and hence there is no dependency to JSP2.1 container.
Has anyone deployed JSF1.2 application in servlet2.4 based conatiner (e.g: WLS 9.2 or Tomcat 5.5.2)?
I would appreciate if someone can provide articles / links to articles which clarify this point explicitly.

Note: I looked into JSF1.2 specs and it is not clear.

Thanks
16 years ago
JSF
You can find answers to sharpen your pencils in the following link:
answers for sharpen your pencils partB
Hi Guys,
Do u have any idea when the book is available in Europe?
Has anyone got the book in Europe?
HFEJB is correct.
option 1, has a create() method which takes a string parameter. This is MEANINGFUL only for stateful session beans.
The container decides when to passivate a bean. This would be typically determined based on the resource availability. This feature is entirely dependent on the vendor. ( A vendor can decide to passivate after every method call. Another vendor would passivate a bean based on some caching algorithm only when the memory resources are short).

Similarly the EJB spec specifies, that a container must have the capability to remove a stateful bean on its own if it remains idle for certain duration.
How it is implemented is entirely container / vendor dependent.

Lets consider weblogic EJB container. It provides two parameters for the deployer to configure:
1) max-beans-in-cache: This is the maximum allowed stateful bean instances in cache
2) idle-timeout-seconds: time upto which a stateful bean can remain idle after which it can be removed from cache.

For example: consider the following configuration:
max-beans-in-cache: 2
idle-timeout-seconds: 600

Scenario1:
There are two beans EJB1 and EJB2. EJB1 is in the middle of executing a method. EJB2 has been idle for 20 seconds.
When a request comes to create a new stateful bean, EJB2 would be passivated , as the max-beans-in-cache has reached and EJB2 is idle.

Scenario2:
There are two beans EJB1 and EJB2. EJB1 is in the middle of executing a method. EJB2 has been idle for 601 seconds.
When a request comes to create a new stateful bean, EJB2 would be removed , as the max-beans-in-cache has reached and EJB2 is idle for more than the allowed duration.

The important point to remember is that, conatiner has the ability to passivate or remove a stateful bean. The bean provider should consider this when developing an application using stateful beans.
How this would be handled is entirely dependent on the container.

Refer to the stateful bean lifecycle in EJB specs: section 7.6, page 77.

Regarding your question

Im still not clear how the container decides when to call remove and when to call passivate. Is it that passivate timeout < remove timeout?



IF a container provider does passivation and removal based on only two parameters (say) passivate-timeout and remove-timeout, then inorder to use the resources effectively, passivate-timeout must be less than remove-timeout. If remove-timeout > passive-timeout, then passivation will never take place. The bean will be removed directly after the specified timeout period.
[ January 01, 2006: Message edited by: Sankar Subbiramaniam ]
run j2ee.bat. (Before running j2ee.bat, set proper values JAVA_HOME to the path where you have JDK installed and set J2EE_HOME to the path where you have installed j2sdkee).
If you still have problems, give details of the error you are getting.
Code would compile. but whether it would deploy or not depends on the container provider.

EJB specs, 9.5.2, page 113 states the following:

There is a unique findByPrimaryKey(primaryKey) method for an entity bean on its remote home interface; this method must not be overloaded



The above implies you as a Bean provider must ensure that the component interface complies to the above guideline. Unless you comply to EJB specs, you cannot guarantee code portability (WODA).

For the exam, HFEJB has explained what a "can" means. I suggest you to follow that rule strictly.
Consider the scenario:
Servlet A calls two stateless beans SEJB1 and SEJB2. Both the stateless beans in turn call an entity bean EEJB1.

Lets say servlet A starts transaction TX1 and then calls simultaneously (using thread) SEJB1 and SEJB2.

Both SEJB1 and SEJB2 will call EEJB1 with the same transaction TX1.

To entity bean EEJB1, SEJB1 and SEJB2 are two different clients.

Hope this helps.
A entity bean can have only one primary key and hence only one meaningful findByPrimaryKey() is possible and allowed.
Keyword: manifest file

In EJB2.0 and ejb-jar is not required to have a manifest file. So normally you msut have the following entries in your ejb jar file:
1) Home interface
2) Component interface
3) Your bean class
4) ejb-jar.xml in META-INF directory.

But if you wish you can package your jar file as follows:

1) ejb-jar.xml in META-INF directory.
2) manifest file referring to Home/Component and Bean classes

In the second approach you are indirectly referring to your Home/Component/Bean classes.
Two entity beans will be equal if and only if they meet the following criteria.
1) The both have the same home interface
2) They both have the same primary key

Now you can infer yourself what isidentical(9 would return.