|
I
fully agree with victor. Its the situation which judges the solution not some
ones gut feeling. We have been doing J2EE Applications but we dont have any
softcorner for any specific technology. In any case whoz this
Brett?
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".
===========================================================================
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".
|
