Hi Tibor,
I may have no answers but volunteer to discuss the issue with You...
- Original Message -
From: Tibor Hegyi
My test application scenario is: servlet-SLSB-SFSB-Entity. (A - B:
means A instantiates B and calls business methods on it)
1. When the SLSB bean looks up the home interface of SFSB, the SFSB's
ejbActivate is called a few dozens times. Why? Does Orion create pre-pooled
instances of Stateful session beans (before they have been created
explicitely)? Strange. The same number of ejbPassivate-calls are performed
when I shut down the server.
No. ejbActivate() is called when a bean needs to be in ready state. One
possible explaination could be that Orion persists SFSB so that they survive
a server restart. This is an option in the spec which Orion chooses to
implement. Fine so far.
Something looks dangerous: You create a SFSB from a SLSB. I would presume
that each time you instantiate the SFSB you create a new instance - even if
you are in the same session!! The correct way (IMHO) is to instantiate a
SFSB from a servlet of session scope and store its reference in its session
context. As always, I may be wrong.
2. What does the number of this kind of pre-pooled beans depend on?
Strange. I changed the timeout value in orion-eib.jar from 1800 sec to 10
sec but Orion behaves the same way. Strange.
The SFSB should go away (return to pooled state calling ejbPassivate())
after the session expires.
It seems to me that Orion somehow remembers the maximum number of usage of
a SFSB and next time after orion is RESTARTED it creates the same number of
pseudo-instances as I described above. Could this be the case?
No. cf. my text above.
Entity beans:
I set up max-instances and validity-timeout attributes in orion-ejb.jar.
Despite this:
1. When issuing a findAll (or any multiple result findXXX method) method
call on the Entity Home the number of instances may exceed the max-instances
setting. Hence the number of entity instances can increase endlessly
potentially causing an out-of-memory problem. Strange.
Are you sure?
Normally, EB are reused from one business method to another. Maybe, You
touch *all* members of the collection returned from the finder within a
single transaction? BTW, if two business methods overlap in time, an EB may
exist in multiple instances even for the same primary key! When recursions
occur you need to start to think about proper EB deployment settings. Orion
has a flag wether to preload EBs on a finders. The flag defaults to true.
Maybe, you need to set it to false?
Anyway, the max-instance setting may only affect EBs not currently in a
business method.
2. After the validity-timeout has elapsed AND the number of max-instances
was exceeded AND a new instance is being created, the non-valid (over
validity-timeout) ones are removed from the pool.
Looks ok, because you are between two business methods. The max-instance
setting can only become effective when a new instance is needed AND there
*are* any idle EBs (when a new one is created the server needs to decide
wether to passivate an existing EB or to create a new one. Why should the
server ever touch an EB outside this decision making?).
So that's it. If anyone could give us (some might also be interested in
this topic) explanation or share his/her expreiences I would appreciate very
much.
Tibor Hegyi
Falk
--
Dr. Falk Langhammer
Living Pages Research GmbH
Holzstr. 19 D-80469 Munich, Germany
mailto:[EMAIL PROTECTED] http://www.living-pages.de
Phone +49 (89) 260 255 32Fax +49 (89) 260 255 35
