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
Martin
______________________________________________
Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung / Note de déni et de confidentialité
This message is confidential. If you should not be the intended receiver, then we ask politely to report. Each unauthorized forwarding or manufacturing of a copy is inadmissible. This message serves only for the exchange of information and has no legal binding effect. Due to the easy manipulation of emails we cannot take responsibility over the the contents.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Sun, 26 Apr 2009 17:07:14 -0400
> From: mark_at_mark.mielke.cc
> To: users_at_glassfish.dev.java.net
> Subject: Dependency injection - when to clean up injected resources?
>
> This feels like a newbie question - but it seems like this is a friendly
> group, and I've read through all of the specs and faqs and plenty of
> examples and I have been unable to find a solid answer here.
>
> Most examples of dependency injection do not clean up the injected
> resources. Whether DataSource, EntityManager, or EJB. The resource is
> injected, it is used, and resources allocated from it (like a Connection
> from a DataSource) are cleaned up, but the injected resource itself is
> not cleaned up.
>
> My assumption has been that these resources are safe to leave around.
> That is, they're only taking up memory which is the job of the garbage
> collector to deal with. They're not tying up any resources. In some
> cases like EntityManager or a UserTransaction, the container will always
> clean up any non-memory references held after the business method
> returns when the transaction is committed or rolled back.
>
> This conclusion sat well with me until I started looking into the use of
> stateful session beans.
>
> For stateless session beans, my understanding is that the container
> manages a pool that is only assigned when a method is invoked, and added
> back to the pool when done, so I think stateless session beans are safe
> to never explicitly remove.
>
> For stateful session beans, however, nothing in the spec seems to
> suggest to me that it will automatically run the @Remove method on a
> stateful session bean. But, in many of the examples I find, including
> ones on "official" sites like openejb, they eject a new stateful session
> bean into the client object and then never remove it. Does this not lead
> to the container having stale EJB sessions lying around, perhaps
> passivated? If invoked 1 million times, does this leave 1 million
> sessions being managed by the container but not being referenced by any
> client? Should these examples be corrected?
>
> What is the best place to do this cleanup? Should @PostDestroy method on
> the object receiving the injection be explicitly running the @Remove
> method on all injected stateful session beans (assuming they are not
> being saved for later user)?
>
> What about JSF managed beans that inject using @EJB? Should they also
> remove all stateful session beans from the @PostDestroy method?
>
> Are there other dependency injected objects that require explicit
> cleanup during @PostDestroy?
>
> Thanks for any help in clearing me up on this.
>
> Cheers,
> mark
>
> P.S. I am a happy GlassFish user - hoping Oracle keeps it around.
>
> --
> Mark Mielke <mark_at_mielke.cc>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
_________________________________________________________________
Rediscover Hotmail®: Get quick friend updates right in your inbox.
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates2_042009