Here's my experience with this issue. We used
in-memory session failover in WL, but due to problems
with the WL proxy we switched to JDBC session
persistence. We then dropped clustering and session
persistence altogether because of performance reasons
and used switches to make sure that users always hit
the same WL instance.
Things to note about my experience:
* There were ways to optimize the session database
(Oracle) which we didn't explore.
* Session failover wasn't as important as we thought.
At least not more so than performance.
Calvin
--- "Chen, Yong" <[EMAIL PROTECTED]> wrote:
> Application server level load balancing is the
> answer to the problem.
> I don't see there is a strong reason to synchronize
> two sessions on two different app servers. Because
> the web server or proxy server will establish the
> link between the client and app server the very
> first time the connection is made. After that, the
> client (browser) will bind to the same app server.
> So, session info should only be kept in that
> particular app server.
>
> However, if you want to do session level fail-over,
> then like Weblogic app server, you will utilize
> their cluster feature to sync the secondary app
> server with the primary app server in case the
> primary is down. This requires to use BEA's weblogic
> proxy feature to detect such failure of primary app
> server down.
>
> In current generation of web apps, should any
> services is needed to be distributed, you can use
> EJB, RMI, CORBA or COM/COM+. Session related info
> should be in the memory of app server. Session is
> transient, not persistent.
>
>
> Yong Chen
>
> -----Original Message-----
> From: Peter Smith [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 23, 2001 5:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: FW: Session scope
>
>
> I'm definitely considering running Struts with at
> least 2 JVMs - one on each of 2 boxes. At first I
> didn't even consider the effects of running multiple
> JVMs - never done it!
>
> Currently, my company has a big Oracle focus.
> There's
> only one Oracle instance so they're using it to
> maintain session info across multiple app servers.
> This requires a db hit for every HTTP request.
>
> I can handle the memory requirements. I just want a
> better way to coordinte session info across JVM's.
>
> In the past I've written a poor-man's
> 'serialization'
> module for PERL which just kicked-out all the
> accumulated HTML parameters into <HIDDEN...> tags.
> Wonder if I can do something similar for Struts
> environment w/o giving up too much of the
> functionality I'm using Struts for in the first
> place.
>
> Are there any gotchas we can think of with using
> Struts across JVM's?
>
> P.S. I wonder if Tomcat project is planning some
> kind
> of session-sync technology.
>
> --- "Maguire, James" <[EMAIL PROTECTED]> wrote:
> > Obviously, design decisions have been made on the
> > session context.
> >
> > Is anyone running (or considering running) Struts
> in
> > a truly distributed
> > server infrastructure?
> > Does Craig's suggestion of Serializable session
> > beans stand up under volume?
> >
> > Just looking for some pointers.
> >
> > Jim
> >
> > -----Original Message-----
> > From: Craig R. McClanahan
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, April 13, 2001 11:03 PM
> > To: Struts-User@Jakarta. Apache. Org (E-mail)
> > Subject: Re: Session scope
> >
> >
> >
> >
> > On Tue, 10 Apr 2001, Girish Baxi wrote:
> >
> > > I am a new strut user .... as far as i know ,
> isnt
> > it a bad idea to store
> > > data in the session scope simply becoz its not
> > scalable for a multiple web
> > > server scenario ...
> > > is there any work around to using session scope
> in
> > case of form beans that
> > > span more than one html page ???
> > >
> > > any guidance is appreciated,
> > > thanx
> > >
> > >
> > >
> >
> > Let's understand what is really happening in order
> > to understand what the
> > potential impacts are:
> >
> > * An HttpSession, as implemented by your servlet
> > container, typically
> > uses something like a Hashtable or a HashMap to
> > store session
> > attributes.
> >
> > * When you create a bean instance, the bytecodes
> > that make up the
> > executable methods of your bean are shared
> across
> > all instances -- the
> > only thing that takes memory is the bean
> > properties themselves.
> >
> > * Let's assume that your bean uses about 1000
> bytes
> > for the properties
> > that are unique to that bean, and you want to
> save
> > a bean in each
> > user's session because it represents information
> > you need over more
> > than one request.
> >
> > * If you have 10,000 simultaneous users, that
> means
> > you need roughly
> > ten megabytes (10,000 * 1000) of memory to store
> > these objects. Whether
> > that is a problem or not depends on how much
> free
> > memory you have.
> >
> > * Some application servers support load balancing
> > and distribution
> > facilities, so that they can handle more users
> > than can be supported
> > by a single server. Essentially, they are
> running
> > a copy of your
> > web application on each server. In order to
> > facilitate migrating
> > your session from one server to another, they
> may
> > require you to make
> > all of your session beans Serializable.
> >
> > The bottom line is that, like everything else, use
> > of session beans
> > involves tradeoffs. If you are running amazon.com
> > or Yahoo, you care a
> > lot about memory occupancy. If you're writing an
> > Intranet app for 50
> > users in your department, it's probably not a big
> > deal unless you have
> > very large data objects to be stored. You should
> > analyze your expected
> > simultaneous user counts, and the typical amount
> of
> > memory that their
> > session attributes require. Compare that to the
> > amount of available
> > memory on your server. The results of this
> > comparison will tell you how
> > much (or little) you need to worry about the
> amount
> > of space session
> > variables require.
> >
> > Craig McClanahan
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great
> prices
> http://auctions.yahoo.com/
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
