Hi Martin:
Thanks for the answer - however, I was more interested in why examples
assume removal-timeout-in-seconds will deal with the session rather than
explicitly removing the sessions when they are no longer in use?
It seems to me that I can always create sessions faster than they are
being removed (within computation limits). If I create 1 million
sessions in a row as per examples and as per your response, they would
all continue to exist until removal-timeout-in-seconds has elapsed?
Is leaving sessions around really the recommended behaviour (as defined
by the number of examples with EJB dependency injection who do not
remove sessions when they are done with the them?)?
I can understand that sessions are "lost" for various exceptional
reasons, and removal-timeout-in-seconds makes great sense here. My
concern is that this seems to be recommended even in the normal case and
my programming background instinctively tells me that this is wrong...
Thanks,
mark
Martin Gainty wrote:
> Good Morning Mark
>
> The activation/passivation times are managed by container attributes
> in your domain.xml e.g:
>
> <ejb-container steady-pool-size="0" pool-resize-quantity="8"
> max-pool-size="32" cache-resize-quantity="32" max-cache-size="512"
> pool-idle-timeout-in-seconds="600" cache-idle-timeout-in-seconds="600"
> removal-timeout-in-seconds="5400" victim-selection-policy="nru"
> commit-option="B"
> session-store="${com.sun.aas.instanceRoot}/session-store">
> </ejb-container>
>
> the most cogent attribute is removal-timeout-in-seconds
>
> Specifies the amount of time a bean instance can remain idle in the
> container before it is removed (timeout). A value of 0 specifies that
> the container does not remove inactive beans automatically. The
> default value is 5400. If removal-timeout-in-seconds is less than or
> equal to cache-idle-timeout-in-seconds, beans are removed immediately
> without being passivated.
> (Applies to stateful session beans)
> http://docs.sun.com/app/docs/doc/820-4502/beawl?a=view
>
> Let us know if this information addresses the situation you are
> experiencing
--
Mark Mielke <mark_at_mielke.cc>