This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
I have stateful bean business interface and class as -
am using glassfish 3.0.1. Using administration tool(http://localhost:4848/common/index.jsf) to configure cache for ejb from
" Common Tasks->Configuration->EJB Container"
I have configured the cache related data as -
Beans can be accessed successfully 3 times causes "postconstruct" to print 3 times. But it does not passivate if it is idle for more than 40 seconds. I could never see "prepassivate" unless glassfish is shutdown.
Can someone explains why bean does not passivate if it is idle for more than 40 seconds?
Thanks in advance!
We will have a future if we save Nature!
I take the liberty of answering your question with a question:
Where have you been able to find something in the EJB specifications that tells you when a stateful session bean should be passivated?
The only statement I have been able to find is this about the stateful session bean lifecycle:
The container’s caching algorithm may decide that the bean instance should be evicted from memory. (This could be done at the end of each method, or by using an LRU policy). The con- tainer invokes the PrePassivate lifecycle callback interceptor method(s) for the bean instance, if any. After this completes, the container saves the instance’s state to secondary stor- age. A session bean can be passivated only between transactions, and not within a transaction.
Thank you very much! Thanks for giving new idea about NRU and LRU. I will take a look at that. So should i conclude that
how and when to passivate bean is completely decided by container on the basis NRU and LRU policy, and may be on the basis of other parameters?
Joined: Oct 04, 2006
If you are preparing for the certification, then I would say that you do not need to concern yourself with things that are not explicitly stated by the EJB specification.
In this case, the specification is vague and I would say that it is deliberate, in order to give container implementers some freedom to decide how to handle bean passivisation and activation.
If you really want to know, then perhaps you should study GlassFish documentation and/or GlassFish source code. The latter is the most reliable source for accurate information, but also the most difficult to read and navigate.
Joined: Dec 26, 2007
Thank you very much!. Yes that is nice idea to read Glassfish3.0 documentation. And your
are true, i do not need to go in such details just now. I am just doing small simple examples and trying to
figure out how container handles things.