Hi Falk,
See my comments
below!
Regards,
Tibor Hegyi
webmiles AG
Ridlerstr. 31b
80339
M�nchen
Tel. 089/ 12469-461
Fax 089/ 12469 - 222
e-mail:
[EMAIL PROTECTED]
-----Urspr�ngliche Nachricht-----
Von:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im
Auftrag von Falk
Langhammer
Gesendet: Donnerstag, 8. M�rz 2001
19:43
An: Orion-Interest
Betreff: Re: Calibrating EJB Pooling in
Orion
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.
[TH] I see the point of ejbActivate(),
but why does Orion put hundreds of instances in the SFSB ready pool before I
used one of them. Furthermore, why the number of these SFSBs are increasing? Let
me give you a bit more detail. My SLSB calls create() on SFSB's home interface
everytime it wants to call a method on the SFSB. This should be ok, since SBs
cannot be identified. In test 1 I performed these steps 100 times. In test 2 I
did it 120 times. So the number of "dummy" SFSBs preloaded in the ready state
got up to 120. How can I decrease or change this number?
Anyway, calling ejbActivate on a SFSB before calling setSessionContext and ejbCreate is somehow violates rules of the lifecycle diagram in chapter 6.6 of the EJB 1.1. spec that says ejbActivate is called when SFSB is activated from the passive state. OK, I'd accept that this is due to Orion's feature of persisting instances of SFSB (where is it in the spec?), but the number of such instances may be huge at the end.
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.
[TH] My scenario might not be nice, but why is it dangerous? In the
sense, that too many SFSBs are created? Well calling remove() on the SFSB would
solve the problem of multiple instances. Anyway the container should passivate
the SFSBs and after the timeout period remove them.
But do you think that the Orion cannot passivate SFSBs while in the Web session is alive? I mean while I keep calling the servlet again and again that calls SLSBs that create and call SFSBs.
I might miss and do something 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.
[TH] Why the SFSBs cannot be
passivated when not referred to anymore? I mean after the method of the SLSB has
executed, the SFSB created in this method should be subject to passivation. But
Orion does not seem doing this. Or it does but behind the
scenes.
>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?
[TH] The scenario is: servlet calls the finder on the home of EB that
returns a collection of the EBs. Orion creates EB instances for the result
set. I do not go through the collection and call any method on the EBs at
all. Although, it is not a good programming practice to query hundreds
or thousands of EBs using finder methods but rather calling
findByPrimaryKey on the ones really needed.
>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?).
[TH]
I think you're right with this. EBs are not passivated in a transaction even if
the number of instances exceeds the limit. Is that OK and does it meet the
specs? I can't see.
