If you think about it, what state could a stateful session been have that it
would need to explicitly persist during passivation? Don't forget, all its
non-transient instance variables will be persisted by the container. The
rule is that after the call to ejbPassivate(), any non-null instance
variables must be references to serializable objects, or other bean
remote/home references, jndi context, etc - all of which the container will
save and restore.
Given all the other restrictions on ejbs, its pretty hard to accumulate much
in the way of non-serializable state, i.e. no file i/o streams, etc. In
general any non-serializable state that a bean might have is better off
being reduced to serializable state (or nullified) in ejbPassivate() and
reconstructed in ejbActivate(). Most non-serializable state you wouldn't
want to persist anyway since it usually represents connections to resources
that would be wasteful to keep during the passivation interval (e.g. network
or db connections).
> If EJBs are not supposed to do file I/O, but stateful session beans
should sae
> their state in a persistent store when they are passivated (which I
believe is
> because the container might crash while the bean is passivated, though it
it is
> written to secondary storage by the container I don't see the need -- what
is up
> with this?), then how is the session bean supposed to sae iuts state?
Unless
> the requirement is to use a database,which would be rather onerous I
think,
> there is a conflict here between what you should do to passivbate a bean
and
> what you're not suppose dto do. How is this supposed tobe resolved?
Thanks.
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
