The main reason stateful session beans are typically the black sheep is because
of the
"thickness". If you check out: http://www.middleware-company.com/debate.html,
Roman
and Sessions argue about a bunch of points between COM+ and EJB.
Roman points out about stateful:
"And yes, there
are scalability concerns with stateful, but a lot of
developers find
stateful very convenient and EJB gives you that choice to use
it."
but later points out:
"So, Roger's assertion is that stateful programming is not meant
for the server side. And I disagree with that. The only
benefit that
stateless programming gives you is extra free memory. You
don't
need as many objects instantiated."
The argument typically against stateful EJBs is that you can't have as
many instances floating around for open use. Which leaves you with stateless
EJBs, which you pointed out correctly as being transient. This means to create
state, I "load" the stateless session bean, use it, and discard it. I do this
time
and time again. The time to load now becomes repetitive and can possibly
be a worse mechanism that stateful session beans.
My typical method is to use stateful beans only for areas where session-based
information is really key. I also try to keep the session information pretty
limited
in scope, so persistence, memory, etc. isn't as much of a problem. So, I think
they can be used, but they should be used only where appropriate.
M.
Laird Nelson <[EMAIL PROTECTED]>
02/11/2000 09:09 PM GMT
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Matthew T. Machczynski)
Subject: Stateful session beans?
Are there any real world examples of stateful session beans being used?
Most of the design patterns I've seen concerning EJBs say to use
stateless session beans wherever possible. Well, given that the state
in a stateful session bean must be regarded as totally transient anyhow,
it seems like it's *always* possible to use stateless session beans
instead. Are stateful session beans the black sheep of the EJB family?
Also, can someone explain the rationale to me for why a session bean is
designated as stateless or stateful only in the deployment descriptor?
Surely there are enough semantic differences between the two that the
decision to be stateful or stateless does not belong at deployment time!
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".
===========================================================================
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".
