Hi Mark
I think your points on the issues with setting a session bean to be stateful
or stateless are somewhat valid. yes the design of a sesison bean is usually
indciative of its intended deployment flag. Having said that I do see the
use of having this seperated. Lets consider the following example: We have a
session bean that acts as a Reference Data Manager for both beans and
clients (note: this object could be replaced with just a jndi lookup). When
the reference manager was created it was assumed that it would service many
clients i.e. stateless. Now in the original design (for performance reasons)
the reference data would be loaded once for all clients since it is
reference data (data that should not be changed). Now after some feedback
from users it appears the some of the data does change but not as frequently
and not edited by users to warrant entity status. So to cater for this the
deployment team decide to force the refresh by setting the flag to stateful
thus one will be created for each client. Whereas with the stateless flag
and depending on the client servicing policy we cannot be sure what will
happen we might get new data or just old (potentially very old) cached data
in the session beans fields.
William
> -----Original Message-----
> From: Laird Nelson [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, February 16, 2000 2:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Stateful session beans?
>
> MARK HAPNER wrote:
>
> > Some elements of the EJB DD are dependent on its implementation.
>
> I don't know what this means.
>
> > Development and deployment tools will help keep these in sync.
>
> This makes me nervous for future revisions of the specification. I have
> no problem with something being broken out from code when changing it
> does not fundamentally alter the semantics or behavior of the code. But
> I do have a problem with having to rely on a/several specific tool(s) to
> ensure that changes to one thing don't affect changes to the other. How
> should one go about ensuring that no mistakes occur? What about when
> things are checked into version control systems? What if the deployment
> descriptor is branched/modified/hacked but its code is not?
>
> > It was an
> > explicit EJB design decision to limit EJB code to the minimum needed.
>
> IMHO too much was put in the deployment descriptor.
>
> > It would have been a bad design decision to use encoding in Java as a
> > way to make deployment info 'read-only'. It is much clearer to keep code
> > and deployment info clearly partitioned.
>
> What about stateful and stateless session beans? The way a session bean
> is conceived of, designed and coded is entirely dependent on whether
> it's stateful or stateless. What benefit does putting the statefulness
> flag in a descriptor have here? How is this a good example of
> partitioning? Isn't statefulness something that should be encapsulated
> by the bean itself and not by an external resource? What about issues
> of keeping the two files (code/descriptor) in sync, since they must be
> if the bean is to work properly?
>
> Cheers,
> Laird
>
> ==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
