While the client-view of a stateless session is almost identical to that
of a statefull session, a client program is in general aware of the fact that
it communicates with a stateless object.
Of course, the EJB spec does NOT allow a component to change from
stateful or stateless or vice-versa at runtime, or even deployment time.
Making a session bean stateless is a development time decision which
becomes "structural part" of the component, and cannot be changed later.
Vlada
----- Original Message -----
From: LAURENCE CABLE <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 26, 1999 8:44 AM
Subject: Re: Servlets -> EJB Session Persistence
> Hi Jon,
>
> > On your discussion of recreating STATELESS session-beans for each request:
> > Is the client of SessionBeans really entitled to know wheather a SessionBean is
>STATELESS or
STATEFUL?
> > Your strategy for STATELESS gives hard maintenance problems when a SessionBean at
>a later stage
of development is required to change from STATELESS to STATEFUL. (This could be at a
late time at
for, example, optimization-time.)
> > Or perhaps the design of a STATELESS sessions always requires client-knowledge of
>this property,
and that this property never changes in system-lifetime? Some real-world experience on
this?
> >
>
> My immediate and naive assumption is that a client must be aware (to
> some extent)
> of the nature of the session bean, if for no other reason that error
> recovery. If the
> bean is "stateless" then server failure and loss of a stateless bean
> requires a different recovery model than in the case when a stateful
> bean meets an unexpected demise?
>
>
> - Larry.
===========================================================================
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".
