thats impossible to do completely A refresh of a browser is for example 1 And that would be quite annoying that you have to do that because you have some kind of configuration on the serverside
johan On Wed, Mar 11, 2009 at 18:17, Martin Grotzke <[email protected]>wrote: > 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] > > > > > > > >
