Hey
"Kenneth D. Litwak" wrote:
> 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.
I think Alans and Chris' replies answer the "How?" part well, but
there's still the "Why?" part. The reason for storing the state, or
passivation at all, is that you do not have infinite memory. If that was
the case then you would never have to passivate stateful session beans.
Passivation will occur if a particular instance has not been used for
awhile, and memory is short.
Passivation is not used as a means of crash recovery, since as a bean
developer you cannot rely on this. It would be possible to introduce
crash recovery for stateful session beans, but it wouldn't be cheap
(basically passivating the instance after each method call).
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
