and to clarify - even if you do need failover and use the store in this
state - the failure will only occur if the node goes down AND user uses a
the backbutton in the browser
-igor
On 3/19/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
if you use sticky sessions and dont need failover it will work in its
current state
if you need failover then the directory where the files are saved needs to
be accessible by the primary and its backup buddy nodes
-igor
On 3/19/07, Weaver, Scott <[EMAIL PROTECTED]> wrote:
>
> I have been half following the development of the 2nd-level cache. How
> well will this work in load-balanced environments if at all? We run a
> load-balanced environment in BEA 9.2 and it would be required that the
> 2nd-level cache support this.
>
> Thanks,
> -scott
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto: wicket-user-
> > [EMAIL PROTECTED] On Behalf Of Eelco Hillenius
> > Sent: Monday, March 19, 2007 1:42 PM
> > To: [email protected]
> > Subject: Re: [Wicket-user] Best practice for "singleton" pages
> >
> > On 3/19/07, Weaver, Scott < [EMAIL PROTECTED]> wrote:
> > > Well, it is really not a pool per se (I never write pools anymore).
> I
> > > just want one instance of an arbitrary page per user-session (not
> per
> > > application). So, the first time the user asks for a page it is
> created
> > > for then put onto the session. All subsequent requests for that
> page
> > > would come from the cached copy in the session. This really isn't
> > > "premature optimization" as I tend to be catching a small amount for
>
> > > ridicule from our app server admin about the memory foot-print of my
> > > application. I have checked most of my components and pages and
> they
> > > really don't hold anything huge in the member fields so, I just
> figured
> > > I was getting a build up of pages due to people clicking around in
> the
> > > application. I could be wrong on that, though.
> > >
> > > Would it help if I limit the number of page version allowed?
> >
> > What would help is to use the SecondLevelCacheSessionStore which is
> > the default for Wicket 1.3. That only stores the current page in
> > memory and saves history to a temp dir (which is cleaned up when the
> > session expires).
> >
> > Eelco
> >
> >
> ------------------------------------------------------------------------
> -
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net 's Techsay panel and you'll get the chance to
> share
> > your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> > _______________________________________________
> > Wicket-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
>
> -------------------------------------------------------------------------
>
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
