Well, I've never read Brett McLaughlin's book. I doubt I'll go out and
buy it based on what you've told me so far. What exactly is his
reasoning for saying stateful session beans are so heavy that you need
to avoid them in cases where they are perfectly appropriate?
Based on Mr. McLaughlin's resume, I've been designing/coding
applications a lot longer. Unfortunately too many people pay far too
much attention to a person's credentials instead of reasoned arguments
backed up by actual experiments. Does Mr. Laughlin's book include
actual test cases which demonstrate his point?
--Victor
Mark Galbreath wrote:
Don't know where you got your education, Vic, but you got
cheated. Try reading something from one of the architects, like Brett
McLaughlin's "Java Enterprise Applications, Volume I: Architecture"
(O'Reilly 2002), specifically, the introductory pages 22-23.
Of course, I'm sure your credentials are much better than
Brett's....
Mark
Baloney. That myth continues to causes people to develop really bad
designs. The only overhead a stateful session bean adds is the disk/db
space needed to persist it's data. That's no different that using a
stateless bean and persisting the data in a db table.
Since a stateless bean always losses it's state between
invocations, much greater overhead is incurred since a DB request is
need for each and every call. If you cannot get decent performance with
a stateful session bean in your app server, pick a different one.
That's the whole point of having a J2EE standard.
As pointed out hundreds of times on this list, creating a true
singleton that works in a cluster is very difficult.
--Victor
Mark Galbreath wrote:
Not for something this trivial - stateful
session beans are VERY expensive. Just put whatever you want to
persist in either context scope with a singleton or in entity beans
that map to the appropriate db table(s).
Mark
You can use Stateful session beans
right?.
Hi All,
I have one scenarion. Will
apreciate if you can give some valuable information.
We are currently working on J2EE
application and we ar only dealing with Server side components.
I want to maintain the session
information in EJBS, how can I do that i.e. I want to provide the same
functionality as HttpSession provides in Servlet.
I would also like to know how
it is going to work in cluster enviorment.
Thanks in advance.
Regards,
Saidas Kottawar
MASTEK
"Making a valuable difference"
Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not
that of Mastek Limited, unless specifically indicated to that effect.
Mastek Limited does not accept any responsibility or liability for it.
This e-mail and attachments (if any) transmitted with it are
confidential and/or privileged and solely for the use of the intended
person or entity to which it is addressed. Any review, re-transmission,
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. This e-mail and its attachments have been
scanned for the presence of computer viruses. It is the responsibility
of the recipient to run the virus check on e-mails and attachments
before opening them. If you have received this e-mail in error, kindly
delete this e-mail from all computers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
===========================================================================
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".
===========================================================================
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".
|
