a get request will change the page. For example wicket always tries to redirect to the page. So that a post will always be a normal get to the current page. (so no resend of post data when pressing F5)
But the page that you render can change. For example you can show a listview on that table and some rows are changed because others did do an update on that database data Then the component structure of the page will be changed. So it is not about resending data or do an action again on F5, no it is just getting the latest data from the server. Back to the none sticky sessions: A use clicks on the page (that is a listview with 5 rows) on a link or button That takes a lot of time. So a user does a refresh of that same page That goes to another server then the button click request which is still going on. That last request is fast and returns the same listview of 5 rows. So the page is now in sync with what the user sees. Then the first request goes on and alters the page and now on that point there where only 4 rows left (and i guess now the containter will overwrite this page with the page the user is currently showing in the browser) Then if a user clicks on row 5.. That element isnt there anymore... On Fri, Mar 13, 2009 at 11:58, Martin Grotzke <[email protected]>wrote: > On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote: > > thats impossible to do completely > > A refresh of a browser is for example 1 > Ok, from a technical/academical point of view this is valid. However, > GET requests should not modify any data. For POST-requests the user also > has to confirm that form data is resent. Also users pressing F5 (and > confirming resending of data) all the time are not as common as the well > known double-clickers... > > Did you really had issues with this? What was the setup/conditions in > this case? > > > > > And that would be quite annoying that you have to do that because you > have > > some kind of configuration on the serverside > What do you want to say with this? I don't understand this. > > Cheers, > Martin > > > > > > 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] > > > > > > > > > > > > > > >
