Hi Tibor,
find my comments after each [FL] [TH] clause
--
[FL] 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.
I think, with the additional info you give now things start to look
clearer... I am almost sure that you create a large amount of SFSB (because
you call create that many times) which get passivated either because Orion
needs the memory or because you restart the server. The full calling
sequence is: "setSessionContext->ejbCreate->ejbPassivate->|->ejbActivate"
where you start logging where the '|'-character is. So you miss the calls
before (probably because of a server restart).
BTW, I think it is *not* ok to call create() on SFSB's home interface
everytime you want to call a method on the SFSB. You could create it *once*
per session and store its reference or handle for later use, ideally in a
servlet's session context. A nice feature is that it is forbidden to have
overlapping business method invocations on a SFSB. This makes sense, think
of a customer pushing a "pay" button twice... By creating the SFSB every
time you need it, you disable this mechanism. IMHO, using a SFSB the way you
do renders it a SLSB. Why couldn't you make it a SLSB in the first place?
--
[FL] 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.
You are right, sooner or later the SFSB will go away. Or you call remove
immediately after the busniness call. Orion can and will passivate while the
web session is alive (normally, both have the same timeout of typically 30
min).
The problem is performance: Orion easily processes 200 transactions per
second. Within 30 min, you would have created 360000 SFSBs waiting for
timeout. Depending on the kind of SB you have (time it takes to serialize it
and write to file) this may severely impact performance.
To my understanding, it is a design bug to create a SFSB and not remove it
right away or store its handle for further reference.
--
[FL] 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.
Actually, my first reply was wrong. It must read: "The SFSB should go away
(return to does not exist state calling ejbRemove() after or ejbPassivate()
before the session expires)."
Well, SFSBs are passivated (normally based on a LRU-list algorithm) when the
memory must be reclaimed (controlled by max-instance setting or the amount
of remaining free memory). There is no concept of "not referred to anymore",
thus no garbage collection. When calling a business method on a SFSB be
always prepared to get a "no such object" exception. This is unlike Java
where a reference stays valid forever. However, you do not get this
exception as long as the SFSB is only passivated but has not timed-out yet.
However, you do get this exception even before time-out after a previous
business method throwed a RunTime exception, or passivation failed because
of file-system full, or serialization failed...
What I want to say is: "A SFSB is alway subject to passivation. This happens
independent of clients referring to it, or using it. Clients do not see
passivation as it is normally undone by activation." In your case,
passivation seems to happen only at server shutdown, probably because you do
not reach any passivation threshold before. Timeout causes a SFSB to be
removed, not passivated.
--
[FL] 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.
Is there a flag in Orion's settings whether to create EB instances on a
finder's result set? I know of application servers which do. The logic is
about wether a finder's results will then be used or not.
BTW, this is why here we still are in favour of BMP where we can directly
call SQL select's rather than calling finder methods, or likewise, implement
finders the way we like.
--
[FL] 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.
I looked it up: Within a transaction, a SFSB is in "method ready in TX"
rather than "method ready" and from there, it cannot move to "passive" state
or timeout at all! It is in the same diagram you mentioned earlier (section
6.6 of the EJB1.1 spec).
Falk
(I notice we are both Munich-based. I would not be surprised you phoned ;-))
--
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 32 Fax +49 (89) 260 255 35
