Re: Mainitaining Session in Application Server

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?
  -----Original Message-----
  From: A mailing list for Enterprise JavaBeans development
[mailto:[email protected]]On Behalf Of Victor Langelo
  Sent: Tuesday, December 09, 2003 10:45 PM
  To: [email protected]
  Subject: Re: Mainitaining Session in Application Server


  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
      -----Original Message-----
      From: A mailing list for Enterprise JavaBeans development
[mailto:[email protected]]On Behalf Of Victor Langelo
      Sent: Tuesday, December 09, 2003 10:32 AM
      To: [email protected]
      Subject: Re: Mainitaining Session in Application Server


      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
          -----Original Message-----
          From: A mailing list for Enterprise JavaBeans development
[mailto:[email protected]]On Behalf Of Kumar.K.R
          Sent: Tuesday, December 09, 2003 4:51 AM
          To: [email protected]
          Subject: Re: Mainitaining Session in Application Server


          You can use Stateful session beans right?.
            -----Original Message-----
            From: A mailing list for Enterprise JavaBeans development
[mailto:[email protected]]On Behalf Of Saidas Kottawar
            Sent: Tuesday, December 09, 2003 2:42 PM
            To: [email protected]
            Subject: Mainitaining Session in Application Server


            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".

===========================================================================
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".