Hi, One would need to handle this on the client side, by disabling buttons/links when they are clicked. Also AJAX communicatoin has to be handled, as this is also often a candidate that triggers multiple requests running in parallel.
Cheers, Martin On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: > In my point of view none sticky sessions are just broken or can be broken > very easily > I dont know exactly how all the implementations work but does this example > all ways work? > > a user clicks on a button > that button click does take some time and in the mean time a user clicks on > the same or another button > > In a sticky session configuration this works fine. Wicket makes sure that > they are synced and a page wont be altered by 2 threads at the same time\ > > But how does a none sticky configuration work? Will the second request go to > another server? And just alter there the page state? > It can do that because our sync block doesnt work then ofcourse. > > But if this happens, what happens after that? now the same page instance is > altered on both places.. Which one takes precedence ? > Because it is impossible for the container to merge the objects. So it > should take 1 or the other.. > So the first click that took longer then the second click will overwrite the > second click page. But that now overwritten page is now shown to the user > So if you then click on something that was on the page of the second click > but wasnt on the page of the first click. Then you will get an page expired > or something like that.. > > maybe somehow containers do some synching across concurrent request of 1 > session (hopefully the will send them to the same server) > But i dont know. Synching over servers is very expensive.. then the whole > usage of having none sticky sessions is completely gone in my eyes. > > johan > > On Tue, Mar 10, 2009 at 10:49, Martin Grotzke > <[email protected]>wrote: > > > On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote: > > > Even if you have the memcached store in place, wicket still requires > > > session affinity. Wicket buffers redirect responses locally so the > > > client needs to go to the same server twice or the client will receive > > > an expired session. Wicket is a stateful framework, session affinity > > > is a must. > > Are there other things (besides the buffered response when doing a > > redirect-after-post with the REDIRECT_TO_BUFFER setting) that require > > sticky sessions? > > > > We'd like to use wicket in a stateless mode and defer session creation > > as long as it's possible for a user. Even if wicket is made with a > > statefull programming model in mind we think there are still many > > advantages over other (non-component-based) frameworks. Also we need a > > dynamic structure which would be rather hard to realize/simulate with > > some other component oriented frameworks ;) > > > > Cheers, > > Martin > > > > > > > > > > > > > On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote: > > > > > > > On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote: > > > >> Starts to sound like a form of premature optimization. If you are new > > > >> to Wicket, why do you want to implement a memcached session store? > > > >> What is the usecase? > > > > We're starting a new project (the relaunch of a big ecommerce system) > > > > and want to be able to scale out (just throw in new hardware when > > > > traffic grows). Additionally we have the requirement of session > > > > failover, both in standard operations and for deployments. > > > > > > > > We're discussing non-sticky vs. sticky sessions here and for non- > > > > sticky > > > > sessions memcached (as caching layer in addition to sessions stored > > > > in a > > > > database) is a good candidate, as you don't replicate the changed > > > > session to all other nodes, but only to the primary node for this > > > > session id. This is an important aspect for beeing able to scale out. > > > > > > > > Concerning non-sticky/sticky/memcached/whatever we're not decided yet, > > > > still running in evaluation mode :) > > > > > > > > Cheers, > > > > Martin > > > > > > > > > > > >> > > > >> Martijn > > > >> > > > >> On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke > > > >> <[email protected]> wrote: > > > >>> On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote: > > > >>>> I wrote a memcached session manager store for jetty, that our > > > >>>> wicket > > > >>>> app utilizes. Works well, except I can't open source it, > > > >>>> since it was created on the company's dime ;-( > > > >>> Well, most interesting things are not so simple to realize that > > > >>> one can > > > >>> do it in its spare time. But the good point is that we can do such > > > >>> interesting things in our job :) > > > >>> > > > >>>> > > > >>>> Here is my opinion on memcached as a session store. > > > >>>> > > > >>>> Memcached will not work well as a wicket session store, due to 1mb > > > >>>> size limits. > > > >>> Good to know, I wasn't aware of this restriction (I still need to > > > >>> read > > > >>> more about this for details). So one is forced to handle resources > > > >>> eating much memory (e.g. fileupload) not via session, which is the > > > >>> case > > > >>> even without this 1 mb size limit :) > > > >>> > > > >>> Do you have a case where this limit is important especially for > > > >>> wicket? > > > >>> > > > >>>> You honestly don't want to serialize anything past 100kb > > > >>>> in size due to performance reasons. > > > >>> Right. > > > >>> > > > >>>> That said, It works best if you > > > >>>> use memcached as a container httpsessionstore with the wicket > > > >>>> secondlevelcache diskpagestore. The only thing you need to > > > >>>> serialize > > > >>>> is the last pagemap which should only be 50kb in size max. You > > > >>>> still > > > >>>> get fail over since the last page map is distributed. > > > >>> And I have to read about page maps (I'm really new to wicket as you > > > >>> see :)). AFAIK page maps store a configurable numer of versioned > > > >>> pages > > > >>> for back-button support and versioned pages. > > > >>> > > > >>>> > > > >>>> One thing you need to be careful with is not referencing anything > > > >>>> that > > > >>>> got stored on disk from your active pagemap, it will spiral into a > > > >>>> stack overflow. > > > >>>> > > > >>>> https://issues.apache.org/jira/browse/WICKET-2138 > > > >>> Thanx! We would need to setup tests to be sure that this won't > > > >>> happen. > > > >>> > > > >>> Thanx for your input, > > > >>> cheers, > > > >>> Martin > > > >>> > > > >>> > > > >>>> > > > >>>> > > > >>>> -Victor > > > >>>> > > > >>>> On Mar 8, 2009, at 3:25 PM, Martijn Dashorst wrote: > > > >>>> > > > >>>>> You can check the TIM integration work from the Terracotta guys. > > > >>>>> That > > > >>>>> should make things easier, and you could even try it out, perhaps > > > >>>>> saving a memcached implementation completely :) > > > >>>>> > > > >>>>> Martijn > > > >>>>> > > > >>>>> On Sun, Mar 8, 2009 at 11:01 PM, Martin Grotzke > > > >>>>> <[email protected]> wrote: > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> we're just thinking about a session store using memcached. I just > > > >>>>>> want > > > >>>>>> to ask if somebody already implemented this (and wants to share) > > > >>>>>> before > > > >>>>>> we implement this. > > > >>>>>> > > > >>>>>> Btw, is there some documentation about ISessionStore semantics, > > > >>>>>> in > > > >>>>>> addition to javadocs? I would be interested in the order in > > > >>>>>> which the > > > >>>>>> different methods would be invoked. > > > >>>>>> > > > >>>>>> Thanx && cheers, > > > >>>>>> Martin > > > >>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> -- > > > >>>>> Become a Wicket expert, learn from the best: > > http://wicketinaction.com > > > >>>>> Apache Wicket 1.3.5 is released > > > >>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > > >>>>> > > > >>>>> > > --------------------------------------------------------------------- > > > >>>>> To unsubscribe, e-mail: [email protected] > > > >>>>> For additional commands, e-mail: [email protected] > > > >>>>> > > > >>>> > > > >>>> > > > >>>> > > --------------------------------------------------------------------- > > > >>>> To unsubscribe, e-mail: [email protected] > > > >>>> For additional commands, e-mail: [email protected] > > > >>>> > > > >>> > > > >> > > > >> > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > >
signature.asc
Description: This is a digitally signed message part
