Re: Disabling serialization/storage of pages in session?
Hi Timo, Thanks for the suggestion -- I definitely agree that using the source code and reading it thoroughly will help us understand the inner workings of Wicket. However, I would call that a "white box" approach. :) My hope was to see if I might find some explanations and answers from the experts. It's nice having active message boards where the real developers participate and answer questions, provide examples, and offer suggestions. I'll continue to post questions as we try more things with Wicket. So far, we really like it! - Lu Timo Rantalaiho wrote: > > On Fri, 16 Nov 2007, saenz wrote: >> In fact, I can't tell whether the IPageMap or the IPageVersionManager (or >> both) are used to serialize old versions of Page instances. I would >> assume >> that IPageVersionManager is where this is implemented, but I can't be >> sure. >> The ISessionStore interface has 14 methods and only 1 line of class >> documentation. The IPageMap interface has 16 methods and no class >> documentation. The IPageVersionManager has 13 methods; it has more class >> documentation, but it does not mention page serialization. >> >> Granted, I have not read the Wicket source code. However, I was hoping >> that >> application developers should not expect to have to read the source code >> to >> understand the framework. > > Attaching Wicket sources to your IDE, and having wicket-examples > sources open in adjacent IDE window, will help you a lot. e.g. > > mvn -DdownloadSources=true eclipse:eclipse > > The same goes for any third-party library or framework (and > that's one of the benefits of them being open source; you're > guaranteed the access to the real source code). > >> Please feel free to tell me to RTFM -- but if you do, please at least >> tell >> me where the M is and which chapter to read! :) > > Use the source, Luke! And just try things out, with wicket- > examples or quickstart it's easy and a lot more efficient > than trying to think of things beforehand. > > Best wishes, > Timo > > -- > Timo Rantalaiho > Reaktor Innovations Oyhttp://www.ri.fi/ > > > ------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13816999 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
On Fri, 16 Nov 2007, saenz wrote: > In fact, I can't tell whether the IPageMap or the IPageVersionManager (or > both) are used to serialize old versions of Page instances. I would assume > that IPageVersionManager is where this is implemented, but I can't be sure. > The ISessionStore interface has 14 methods and only 1 line of class > documentation. The IPageMap interface has 16 methods and no class > documentation. The IPageVersionManager has 13 methods; it has more class > documentation, but it does not mention page serialization. > > Granted, I have not read the Wicket source code. However, I was hoping that > application developers should not expect to have to read the source code to > understand the framework. Attaching Wicket sources to your IDE, and having wicket-examples sources open in adjacent IDE window, will help you a lot. e.g. mvn -DdownloadSources=true eclipse:eclipse The same goes for any third-party library or framework (and that's one of the benefits of them being open source; you're guaranteed the access to the real source code). > Please feel free to tell me to RTFM -- but if you do, please at least tell > me where the M is and which chapter to read! :) Use the source, Luke! And just try things out, with wicket- examples or quickstart it's easy and a lot more efficient than trying to think of things beforehand. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
And then to be even more clear
when you do the code below that eelco has given you as an example
the back button wil NOT work anymore.
johan
On Nov 17, 2007 2:23 AM, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > You could also explain some of the details of what should be returned by
> our
> > override of WebApplication.newSessionStore(). The javadoc for this
> method
> > reads "typically not something clients reimplement" so I assume we
> really
> > need to know what we're doing if we override this method.
>
> This in your application class is what I meant:
>
>@Override
>protected ISessionStore newSessionStore() {
>
>return new SecondLevelCacheSessionStore(this, new
> IPageStore() {
>
>public boolean containsPage(String sessionId,
> String pageMapName,
> int pageId, int pageVersion) {
>return false;
>}
>
>public void destroy() {
>}
>
>public Page getPage(String sessionId, String
> pagemap, int id, int
> versionNumber, int ajaxVersionNumber) {
>return null;
>}
>
>public void pageAccessed(String sessionId, Page
> page) {
>}
>
>public void removePage(String sessionId, String
> pagemap, int id) {
>}
>
>public void storePage(String sessionId, Page page)
> {
>}
>
>public void unbind(String sessionId) {
>}
>});
>}
>
> Eelco
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Disabling serialization/storage of pages in session?
> You could also explain some of the details of what should be returned by our
> override of WebApplication.newSessionStore(). The javadoc for this method
> reads "typically not something clients reimplement" so I assume we really
> need to know what we're doing if we override this method.
This in your application class is what I meant:
@Override
protected ISessionStore newSessionStore() {
return new SecondLevelCacheSessionStore(this, new IPageStore() {
public boolean containsPage(String sessionId, String
pageMapName,
int pageId, int pageVersion) {
return false;
}
public void destroy() {
}
public Page getPage(String sessionId, String pagemap,
int id, int
versionNumber, int ajaxVersionNumber) {
return null;
}
public void pageAccessed(String sessionId, Page page) {
}
public void removePage(String sessionId, String
pagemap, int id) {
}
public void storePage(String sessionId, Page page) {
}
public void unbind(String sessionId) {
}
});
}
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
you know, the code is all there. you could just look at it... -igor On Nov 16, 2007 5:04 PM, saenz <[EMAIL PROTECTED]> wrote: > > Hi Martijn, > > I think so. > > You could let us know if we should subclass Application directly or subclass > WebApplication. I would assume the latter. > > You could also explain some of the details of what should be returned by our > override of WebApplication.newSessionStore(). The javadoc for this method > reads "typically not something clients reimplement" so I assume we really > need to know what we're doing if we override this method. > > Can we simply return a new instance of HttpSessionStore? I can't tell if we > need to do this or if that is already the default behavior. I also can't > tell if the HttpSessionStore's PageMap or PageVersionManager will store old > versions of Page instances in memory or on disk, because it is not > documented. > > In fact, I can't tell whether the IPageMap or the IPageVersionManager (or > both) are used to serialize old versions of Page instances. I would assume > that IPageVersionManager is where this is implemented, but I can't be sure. > The ISessionStore interface has 14 methods and only 1 line of class > documentation. The IPageMap interface has 16 methods and no class > documentation. The IPageVersionManager has 13 methods; it has more class > documentation, but it does not mention page serialization. > > Granted, I have not read the Wicket source code. However, I was hoping that > application developers should not expect to have to read the source code to > understand the framework. > > Please feel free to tell me to RTFM -- but if you do, please at least tell > me where the M is and which chapter to read! :) > > I think Wicket is a fantastic idea and a very well designed framework. We > are thinking about adopting it as our standard, but there is a lot for us to > learn and understand before we make this decision. Any help you and other > experts can provide is greatly appreciated. > >- Lu > > > > > Martijn Dashorst wrote: > > > > How can he be more specific than give you the method you need to override? > > Martijn > > > > On Nov 17, 2007 12:53 AM, saenz <[EMAIL PROTECTED]> wrote: > > > >> > >> Hi Johan, > >> > >> Would you mind being a little bit more specific? Or you may feel free to > >> point me to the documentation that I should read. > >> > >> > >> > >> Johan Compagner wrote: > >> > > >> > Application > >> > *protected* *abstract* ISessionStore newSessionStore(); > >> > > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804076 > >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> > >> > >> ------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Buy Wicket in Action: http://manning.com/dashorst > > Apache Wicket 1.3.0-rc1 is released > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/ > > > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804838 > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > 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]
Re: Disabling serialization/storage of pages in session?
Hi Martijn, I think so. You could let us know if we should subclass Application directly or subclass WebApplication. I would assume the latter. You could also explain some of the details of what should be returned by our override of WebApplication.newSessionStore(). The javadoc for this method reads "typically not something clients reimplement" so I assume we really need to know what we're doing if we override this method. Can we simply return a new instance of HttpSessionStore? I can't tell if we need to do this or if that is already the default behavior. I also can't tell if the HttpSessionStore's PageMap or PageVersionManager will store old versions of Page instances in memory or on disk, because it is not documented. In fact, I can't tell whether the IPageMap or the IPageVersionManager (or both) are used to serialize old versions of Page instances. I would assume that IPageVersionManager is where this is implemented, but I can't be sure. The ISessionStore interface has 14 methods and only 1 line of class documentation. The IPageMap interface has 16 methods and no class documentation. The IPageVersionManager has 13 methods; it has more class documentation, but it does not mention page serialization. Granted, I have not read the Wicket source code. However, I was hoping that application developers should not expect to have to read the source code to understand the framework. Please feel free to tell me to RTFM -- but if you do, please at least tell me where the M is and which chapter to read! :) I think Wicket is a fantastic idea and a very well designed framework. We are thinking about adopting it as our standard, but there is a lot for us to learn and understand before we make this decision. Any help you and other experts can provide is greatly appreciated. - Lu Martijn Dashorst wrote: > > How can he be more specific than give you the method you need to override? > Martijn > > On Nov 17, 2007 12:53 AM, saenz <[EMAIL PROTECTED]> wrote: > >> >> Hi Johan, >> >> Would you mind being a little bit more specific? Or you may feel free to >> point me to the documentation that I should read. >> >> >> >> Johan Compagner wrote: >> > >> > Application >> > *protected* *abstract* ISessionStore newSessionStore(); >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804076 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.0-rc1 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/ > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804838 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
How can he be more specific than give you the method you need to override? Martijn On Nov 17, 2007 12:53 AM, saenz <[EMAIL PROTECTED]> wrote: > > Hi Johan, > > Would you mind being a little bit more specific? Or you may feel free to > point me to the documentation that I should read. > > > > Johan Compagner wrote: > > > > Application > > *protected* *abstract* ISessionStore newSessionStore(); > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804076 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/
Re: Disabling serialization/storage of pages in session?
Johan Compagner wrote: > > what do you mean with disabled? how is it disabled? > The page can't be serialized because of none serializeable attributes? > Then in the default 1.3 configuration that page can't be saved to disk so > you can't restore it. > Hi Johan, What I mean is by using the technique suggested by Eelco in the second message of this thread. Here is the quote: Eelco Hillenius wrote: > >> If need be, can we disable altogether the storage of pages (in the form >> of a >> pageMap) in session, similarly on the disk ? > > Yep. One easy way to achieve this is to provide a dummy page store. > So the question is: If the PageStore is disabled, what will happen when the user presses the back button? Is there any documentation or explanations about how the entire PageStore module works (especially when clustered), and how applications should handle the back button on the browser? Thanks. -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804104 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
Hi Johan, Would you mind being a little bit more specific? Or you may feel free to point me to the documentation that I should read. Johan Compagner wrote: > > Application > *protected* *abstract* ISessionStore newSessionStore(); > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804076 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
what i always wonder.. How do you sync sessions? That's why i think none sticky sessions are just flawed.. Do remember that we in wicket have a single threaded mode. How on earth are you going to do that if you have none sticky sessions? If request a comes in alters the page, but then at +/- at the same time another request comes in to another server that also changes the page... How does the server ever merge that? The last one to leave wins? But that could be the first one that did enter. And if those 2 request would have altered 2 different parts of the page? (ajax requests) What do we have then in memory? I just can't believe that the servlet container can really merge the objects And even then what happens when there is a conflict? So the only thing to do here for a servlet container is to synchronize over the servers But then the whole point of none sticky sessions is just gone. The overhead would be huge. Besides that what does a none sticky session bring you if you talk about performance? do you really thing it is then better balanced? I don't think so. If the numbers are high then because of probability everything will average out for example if you start at 0 then round robin you divide new sessions to 4 different servers.. after 2000 new sessions the servers have 500 sessions each.. then 400 sessions are removed the probabililty tells us that each server will have about +/- 400 sessions left. and not 1 server is dropped to 100 and the other 3 do still have 500 sessions. johan On Nov 16, 2007 6:19 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > round-robin has a couple of disadvantages over sticky sessons: > > a) you need to replicate state to all nodes - a lot of traffic > although with a fiber backplane its most likely not an issue. with > sticky sessions you only have to replicate to one or two other nodes > which act as backup buddies. > > b) you cannot take advantage of data locality. each node can keep its > own cache which over a span of a session gets more attuned to what the > users on that node are doing, if you use round robin then you lose out > on that. > > -igor > > > On Nov 16, 2007 8:51 AM, saenz <[EMAIL PROTECTED]> wrote: > > > > Fair enough. Good answer. :) > > > > Of course I meant in the non-failure case. > > > > So under normal operations outside of failure conditions, perhaps there > > really is no benefit to move users to other nodes during the lifetime of > a > > session, or at least the difficulty outweighs the benefit. > > > > - Lu > > > > > > > > > > Martijn Dashorst wrote: > > > > > > failover? > > > > > > On 11/16/07, saenz <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> Johan Compagner wrote: > > >> > > > >> > On Nov 15, 2007 11:22 PM, Eelco Hillenius < > [EMAIL PROTECTED]> > > >> > wrote: > > >> >> Recommended is to use sticky sessions. > > >> > > > >> > +1 > > >> > > > >> > none sticky sessions are flawed anyway.. (or the synchronizing > > >> performance > > >> > hit is so great it doesn't make any sense, it it makes sense to > start > > >> > with...) > > >> > > > >> > > >> Johan, are you saying that other types of load balancing strategies > > >> besides > > >> sticky sessions are all flawed, and that it only makes sense to use > > >> sticky > > >> sessions? Please correct my understanding. > > >> > > >> If sticky sessions are the only recommended way to do load balancing, > > >> then > > >> what is the reason to support replication of session state across > > >> multiple > > >> nodes in a cluster? > > >> > > >> - Lu > > >> -- > > >> View this message in context: > > >> > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796491 > > >> Sent from the Wicket - User mailing list archive at > > >> Nabble.com<http://nabble.com/> > . > > >> > > >> > > >> - > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > -- > > > Buy Wicket in Action: http://manning.com/dashorst > > > Apache Wicket 1.3.0-rc1 is released > > > Get it now: http://www.apache.org/d
Re: Disabling serialization/storage of pages in session?
hmm that is pretty much killed with the basic 1.3 setting now because we have a file on disk thats pretty much a database file with multiiply pages now but the index of that file, where the page starts is in mem.. so for clustering and a shared disk the only solution we currently have (besides the HttpSessionStore) is the SimpleSynchronousFilePageStore I guess we need a SimpleAsync one to have a performant one? Or look if matej finishes the other. Also is it you should ask yourself is it really importand if you have failover but with sticky sessions that when a failover happens. That only at that small window the back button will trigger a page expired? If they are already 1 or 2 clicks further nothing is wrong. Its just a matter of how high you build the banks. johan On Nov 16, 2007 7:33 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > you can still cluster 1.3.1 easily. either use httpsessionstore or > tell wicket to save pages to a shared drive > > -igor > > > On Nov 16, 2007 10:20 AM, saenz <[EMAIL PROTECTED]> wrote: > > > > > > igor.vaynberg wrote: > > > > > > you will get an error, i have explained this in a parallel thread > > > yesterday... that is why we are working on a special page store that > > > will also write out the current page onto the disk when the session is > > > replicated - that means all nodes will have all the pages spooled to > > > disk so clustering will be transparent... > > > > > > > Thank you Igor. > > > > So for now, is the recommendation to disable disk-based page > serialization > > if a Wicket app is deployed to a cluster? > > > > Do you plan on including the new and improved replicated page store in > > Wicket 1.3 RC or will that be a 2.0 feature? > > > > Also -- if page serialization is disabled, what happens when the user > hits > > the back button? > > -- > > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13797991 > > > > Sent from the Wicket - User mailing list archive at > > Nabble.com<http://nabble.com/> > . > > > > > > - > > 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] > >
Re: Disabling serialization/storage of pages in session?
Application * protected* *abstract* ISessionStore newSessionStore(); johan On Nov 16, 2007 8:54 PM, saenz <[EMAIL PROTECTED]> wrote: > > > > igor.vaynberg wrote: > > > > you can still cluster 1.3.1 easily. either use httpsessionstore or > > tell wicket to save pages to a shared drive > > > > Thanks Igor. Are you saying that we can configure Wicket to store old > versions of Pages in the HttpSessionStore (in memory)? If so, how do we > configure this? > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13800373 > Sent from the Wicket - User mailing list archive at > Nabble.com<http://nabble.com/> > . > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Disabling serialization/storage of pages in session?
what do you mean with disabled? how is it disabled? The page can't be serialized because of none serializeable attributes? Then in the default 1.3 configuration that page can't be saved to disk so you can't restore it. johan On Nov 16, 2007 8:56 PM, saenz <[EMAIL PROTECTED]> wrote: > > Also, can someone answer this other question I asked? > > > saenz wrote: > > > >> Also -- if page serialization is disabled, what happens when the user > >> hits > >> the back button? > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13800441 > Sent from the Wicket - User mailing list archive at > Nabble.com<http://nabble.com/> > . > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Disabling serialization/storage of pages in session?
Also, can someone answer this other question I asked? saenz wrote: > >> Also -- if page serialization is disabled, what happens when the user >> hits >> the back button? > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13800441 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
igor.vaynberg wrote: > > you can still cluster 1.3.1 easily. either use httpsessionstore or > tell wicket to save pages to a shared drive > Thanks Igor. Are you saying that we can configure Wicket to store old versions of Pages in the HttpSessionStore (in memory)? If so, how do we configure this? -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13800373 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
By the way, my question below still has not been answered. Can anyone explain what would occur in the following scenario? > My question regarding on-disk page storage relates to the use case of a > web-app deployed on a cluster. In this situation, what will happen if the > following occurs? > > 1. A user logs in to the wicket app, is directed to node1 by the load > balancer > 2. The user stays on node1 for a few requests and uses page1 a few times, > causing some older versions to be serialized to the disk on node1 > 3. The user then gets redirected to node2 by the load balancer and uses > page1 once more > 4. Now the silly user presses the back button, over and over. > > Is the page storage on node1 is replicated to other nodes? If not, what is > the behavior of Wicket running on node2? > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796998 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
On Nov 16, 2007 10:33 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > you can still cluster 1.3.1 easily. either use httpsessionstore or > tell wicket to save pages to a shared drive Or use that project Matej is working on. It works. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
failover? On 11/16/07, saenz <[EMAIL PROTECTED]> wrote: > > > Johan Compagner wrote: > > > > On Nov 15, 2007 11:22 PM, Eelco Hillenius <[EMAIL PROTECTED]> > > wrote: > >> Recommended is to use sticky sessions. > > > > +1 > > > > none sticky sessions are flawed anyway.. (or the synchronizing performance > > hit is so great it doesn't make any sense, it it makes sense to start > > with...) > > > > Johan, are you saying that other types of load balancing strategies besides > sticky sessions are all flawed, and that it only makes sense to use sticky > sessions? Please correct my understanding. > > If sticky sessions are the only recommended way to do load balancing, then > what is the reason to support replication of session state across multiple > nodes in a cluster? > > - Lu > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796491 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-rc1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
On Nov 16, 2007 8:37 AM, saenz <[EMAIL PROTECTED]> wrote: > Johan, are you saying that other types of load balancing strategies besides > sticky sessions are all flawed, and that it only makes sense to use sticky > sessions? Please correct my understanding. > > If sticky sessions are the only recommended way to do load balancing, then > what is the reason to support replication of session state across multiple > nodes in a cluster? failover -igor > > - Lu > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796491 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > > 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]
Re: Disabling serialization/storage of pages in session?
Johan Compagner wrote: > > On Nov 15, 2007 11:22 PM, Eelco Hillenius <[EMAIL PROTECTED]> > wrote: >> Recommended is to use sticky sessions. > > +1 > > none sticky sessions are flawed anyway.. (or the synchronizing performance > hit is so great it doesn't make any sense, it it makes sense to start > with...) > Johan, are you saying that other types of load balancing strategies besides sticky sessions are all flawed, and that it only makes sense to use sticky sessions? Please correct my understanding. If sticky sessions are the only recommended way to do load balancing, then what is the reason to support replication of session state across multiple nodes in a cluster? - Lu -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796491 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
On Nov 15, 2007 11:22 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > What is the recommended deployment model to support back-button usage > via > > undoable changes and disk-based serialized storage with Wicket? Is it > only > > possible using a load balancer configured to be "sticky" (keep sessions > on > > the same node during the lifetime of the session)? > > Recommended is to use sticky sessions. +1 none sticky sessions are flawed anyway.. (or the synchronizing performance hit is so great it doesn't make any sense, it it makes sense to start with...) johan
Re: Disabling serialization/storage of pages in session?
you can still cluster 1.3.1 easily. either use httpsessionstore or tell wicket to save pages to a shared drive -igor On Nov 16, 2007 10:20 AM, saenz <[EMAIL PROTECTED]> wrote: > > > igor.vaynberg wrote: > > > > you will get an error, i have explained this in a parallel thread > > yesterday... that is why we are working on a special page store that > > will also write out the current page onto the disk when the session is > > replicated - that means all nodes will have all the pages spooled to > > disk so clustering will be transparent... > > > > Thank you Igor. > > So for now, is the recommendation to disable disk-based page serialization > if a Wicket app is deployed to a cluster? > > Do you plan on including the new and improved replicated page store in > Wicket 1.3 RC or will that be a 2.0 feature? > > Also -- if page serialization is disabled, what happens when the user hits > the back button? > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13797991 > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > 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]
Re: Disabling serialization/storage of pages in session?
igor.vaynberg wrote: > > you will get an error, i have explained this in a parallel thread > yesterday... that is why we are working on a special page store that > will also write out the current page onto the disk when the session is > replicated - that means all nodes will have all the pages spooled to > disk so clustering will be transparent... > Thank you Igor. So for now, is the recommendation to disable disk-based page serialization if a Wicket app is deployed to a cluster? Do you plan on including the new and improved replicated page store in Wicket 1.3 RC or will that be a 2.0 feature? Also -- if page serialization is disabled, what happens when the user hits the back button? -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13797991 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
you will get an error, i have explained this in a parallel thread yesterday... that is why we are working on a special page store that will also write out the current page onto the disk when the session is replicated - that means all nodes will have all the pages spooled to disk so clustering will be transparent... -igor On Nov 16, 2007 8:54 AM, saenz <[EMAIL PROTECTED]> wrote: > > By the way, my question below still has not been answered. Can anyone explain > what would occur in the following scenario? > > > > > My question regarding on-disk page storage relates to the use case of a > > web-app deployed on a cluster. In this situation, what will happen if the > > following occurs? > > > > 1. A user logs in to the wicket app, is directed to node1 by the load > > balancer > > 2. The user stays on node1 for a few requests and uses page1 a few times, > > causing some older versions to be serialized to the disk on node1 > > 3. The user then gets redirected to node2 by the load balancer and uses > > page1 once more > > 4. Now the silly user presses the back button, over and over. > > > > Is the page storage on node1 is replicated to other nodes? If not, what is > > the behavior of Wicket running on node2? > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796998 > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > 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]
Re: Disabling serialization/storage of pages in session?
round-robin has a couple of disadvantages over sticky sessons: a) you need to replicate state to all nodes - a lot of traffic although with a fiber backplane its most likely not an issue. with sticky sessions you only have to replicate to one or two other nodes which act as backup buddies. b) you cannot take advantage of data locality. each node can keep its own cache which over a span of a session gets more attuned to what the users on that node are doing, if you use round robin then you lose out on that. -igor On Nov 16, 2007 8:51 AM, saenz <[EMAIL PROTECTED]> wrote: > > Fair enough. Good answer. :) > > Of course I meant in the non-failure case. > > So under normal operations outside of failure conditions, perhaps there > really is no benefit to move users to other nodes during the lifetime of a > session, or at least the difficulty outweighs the benefit. > > - Lu > > > > > Martijn Dashorst wrote: > > > > failover? > > > > On 11/16/07, saenz <[EMAIL PROTECTED]> wrote: > >> > >> > >> Johan Compagner wrote: > >> > > >> > On Nov 15, 2007 11:22 PM, Eelco Hillenius <[EMAIL PROTECTED]> > >> > wrote: > >> >> Recommended is to use sticky sessions. > >> > > >> > +1 > >> > > >> > none sticky sessions are flawed anyway.. (or the synchronizing > >> performance > >> > hit is so great it doesn't make any sense, it it makes sense to start > >> > with...) > >> > > >> > >> Johan, are you saying that other types of load balancing strategies > >> besides > >> sticky sessions are all flawed, and that it only makes sense to use > >> sticky > >> sessions? Please correct my understanding. > >> > >> If sticky sessions are the only recommended way to do load balancing, > >> then > >> what is the reason to support replication of session state across > >> multiple > >> nodes in a cluster? > >> > >> - Lu > >> -- > >> View this message in context: > >> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796491 > >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Buy Wicket in Action: http://manning.com/dashorst > > Apache Wicket 1.3.0-rc1 is released > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796995 > > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > 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]
Re: Disabling serialization/storage of pages in session?
Fair enough. Good answer. :) Of course I meant in the non-failure case. So under normal operations outside of failure conditions, perhaps there really is no benefit to move users to other nodes during the lifetime of a session, or at least the difficulty outweighs the benefit. - Lu Martijn Dashorst wrote: > > failover? > > On 11/16/07, saenz <[EMAIL PROTECTED]> wrote: >> >> >> Johan Compagner wrote: >> > >> > On Nov 15, 2007 11:22 PM, Eelco Hillenius <[EMAIL PROTECTED]> >> > wrote: >> >> Recommended is to use sticky sessions. >> > >> > +1 >> > >> > none sticky sessions are flawed anyway.. (or the synchronizing >> performance >> > hit is so great it doesn't make any sense, it it makes sense to start >> > with...) >> > >> >> Johan, are you saying that other types of load balancing strategies >> besides >> sticky sessions are all flawed, and that it only makes sense to use >> sticky >> sessions? Please correct my understanding. >> >> If sticky sessions are the only recommended way to do load balancing, >> then >> what is the reason to support replication of session state across >> multiple >> nodes in a cluster? >> >> - Lu >> -- >> View this message in context: >> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796491 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.0-rc1 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-rc1/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796995 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
Only the active statefull page is in session. So if you go to the next page then the previous page is gone from the session (and written to the disk for back button support) johan On Nov 15, 2007 11:42 PM, saenz <[EMAIL PROTECTED]> wrote: > > > Johan Compagner wrote: > > > > The DiskStore is for the backbutton and the PageMap (thats in the > session) > > is for the current page. And as long as that page is statefull you have > to > > store it in the session. > > > > What is the lifetime of a Page object stored in the session? > > Does Wicket manage the lifecycle of a Page instance automatically using > some > sort of "garbage collection" mechanism to free the Page instance from the > session state at some point? For example, are Page instances always bound > to > a single request, and freed when the request is completed? > > Or is it the responsibility of the application to free old Page instances > from session state when navigating to different Pages? (It doesn't seem > like > this is the case, but I wanted to ask the question anyway.) > >- Lu > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13783508 > Sent from the Wicket - User mailing list archive at > Nabble.com<http://nabble.com/> > . > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Disabling serialization/storage of pages in session?
Eelco Hillenius wrote: > >> If need be, can we disable altogether the storage of pages (in the form >> of a >> pageMap) in session, similarly on the disk ? > > Yep. One easy way to achieve this is to provide a dummy page store. > My question regarding on-disk page storage relates to the use case of a web-app deployed on a cluster. In this situation, what will happen if the following occurs? 1. A user logs in to the wicket app, is directed to node1 by the load balancer 2. The user stays on node1 for a few requests and uses page1 a few times, causing some older versions to be serialized to the disk on node1 3. The user then gets redirected to node2 by the load balancer and uses page1 once more 4. Now the silly user presses the back button, over and over. Is the page storage on node1 is replicated to other nodes? If not, what is the behavior of Wicket running on node2? What is the recommended deployment model to support back-button usage via undoable changes and disk-based serialized storage with Wicket? Is it only possible using a load balancer configured to be "sticky" (keep sessions on the same node during the lifetime of the session)? Thanks, - Lu -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13782634 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
Johan Compagner wrote: > > The DiskStore is for the backbutton and the PageMap (thats in the session) > is for the current page. And as long as that page is statefull you have to > store it in the session. > What is the lifetime of a Page object stored in the session? Does Wicket manage the lifecycle of a Page instance automatically using some sort of "garbage collection" mechanism to free the Page instance from the session state at some point? For example, are Page instances always bound to a single request, and freed when the request is completed? Or is it the responsibility of the application to free old Page instances from session state when navigating to different Pages? (It doesn't seem like this is the case, but I wanted to ask the question anyway.) - Lu -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13783508 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
> What is the recommended deployment model to support back-button usage via > undoable changes and disk-based serialized storage with Wicket? Is it only > possible using a load balancer configured to be "sticky" (keep sessions on > the same node during the lifetime of the session)? Recommended is to use sticky sessions. But you can configure Wicket to use HttpSessionStore to work with normal cluster synchronization (the stuff that is typically shipped with app servers). You can check out http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-jetty-cluster and http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-jetty-cluster-pagestore for Jetty-specific work in progress where we (or rather, Matej) build an secondlevelcachesessionstore/ pagestore optimized for working in a cluster. And as a whole different approach, you can configure Terracotta to do the clustering for you. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
its pretty accurate yes but a back link on V2 to V1 is a pretty special made thing Because there is normally not really a link to a previous page. Because on the javaside you don't know that really. But you can ask for a specific page version if you want. johan On Nov 13, 2007 3:07 PM, Aqeel <[EMAIL PROTECTED]> wrote: > > I think your example should be simplified to include only Page A. Imagine > the > Facebook profile page: > > - You can add a wall post and after that you land on the same page with > the > new post shown on top. > - This (in Wicket's way) should create 2 versions of your FB profile page. > One with the posted message (v2) and the one before that (v1). > - Now a back link from v2 should (if you have used PageMap) bring you to > the > version 1 state of the profile page. > > Johan, Please correct me if I am wrong. > > - Aqeel > > > > mfs wrote: > > > > In what context are you refering to the back button here...Lets say we > > have two page instances of type "Page-A" through which we landed on > > "Page-B" which has a back button on it, now clicking the back butoon > > should load the "Page A" from the pageMap since its last accessed > instance > > of Page-A...isnt it ? Why do you say that pressing the back button once > > will load the page from the disk... > > > > > > > > Johan Compagner wrote: > >> > >> if you press the back button only once then the page needs to come from > >> disk. > >> > >> So if your users never use the back button then yes you only need to > have > >> the last accessed page in the pagemap. > >> > >> johan > >> > >> On Nov 9, 2007 10:36 PM, mfs <[EMAIL PROTECTED]> wrote: > >> > >>> > >>> I agree..and i would say its mostly the nature of the applications > which > >>> would help determining whether storing the data in the wicket session > >>> would > >>> be a good idea or not... > >>> > >>> Further i believe that 99% of the times one just comes to the need of > >>> accessing the last page-instances (lets say through back button link > or > >>> otherwise doing a refresh if on the same page)...i still couldnt think > >>> of > >>> scenarios where the older page-instances (which are being serialized) > >>> would > >>> come to help...If someone could discuss/point some of those > >>> sceanrio/use-cases..that would be helpful..and would be able to better > >>> justify the wicket's default behavior of serializing. > >>> > >>> Thanks and Regards, > >>> > >>> Farhan. > >>> > >>> > >>> > >>> Gwyn wrote: > >>> > > >>> > Hi, > >>> > > >>> > It's not hard to do it with Wicket, but I'm fairly sure that > >>> > for the typical web-app, the metrics showed that the a re-request to > >>> > database wasn't a big issue, whereas the gain in terms of reducing > the > >>> > session size was, especially where it needs replicating. > >>> > > >>> > As such, the recommendation is as it is, but it's not > >>> > one-size-fits-all, and if you have a large enough percentage of > >>> > non-DB-cachable operations in the DB-layer, you can store the > results > >>> > in the session, etc, without much of a problem. > >>> > > >>> > It's not going to be so built-in as to be trivial, though, as we > want > >>> > to make it clear that anyone doing that is going against the flow. > >>> > > >>> > On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: > >>> > sb> Most database expensive operations come from the result of > stored > >>> > sb> procedures(my current experience at least). A cache solution can > >>> be > >>> > sb> implemented by caching the method results with spring(in case of > >>> using > >>> > sb> spring) but is a heavy(difficult) thing to maintain that "cache" > >>> per > >>> > user - > >>> > sb> http session is a nice and easy storage for that-. > >>> > > >>> > > >>> > sb> Eelco Hillenius wrote: > >>> >>> > >>> >>>> You should use a second level cache to cache objects and queries > >>>
Re: Disabling serialization/storage of pages in session?
I think your example should be simplified to include only Page A. Imagine the Facebook profile page: - You can add a wall post and after that you land on the same page with the new post shown on top. - This (in Wicket's way) should create 2 versions of your FB profile page. One with the posted message (v2) and the one before that (v1). - Now a back link from v2 should (if you have used PageMap) bring you to the version 1 state of the profile page. Johan, Please correct me if I am wrong. - Aqeel mfs wrote: > > In what context are you refering to the back button here...Lets say we > have two page instances of type "Page-A" through which we landed on > "Page-B" which has a back button on it, now clicking the back butoon > should load the "Page A" from the pageMap since its last accessed instance > of Page-A...isnt it ? Why do you say that pressing the back button once > will load the page from the disk... > > > > Johan Compagner wrote: >> >> if you press the back button only once then the page needs to come from >> disk. >> >> So if your users never use the back button then yes you only need to have >> the last accessed page in the pagemap. >> >> johan >> >> On Nov 9, 2007 10:36 PM, mfs <[EMAIL PROTECTED]> wrote: >> >>> >>> I agree..and i would say its mostly the nature of the applications which >>> would help determining whether storing the data in the wicket session >>> would >>> be a good idea or not... >>> >>> Further i believe that 99% of the times one just comes to the need of >>> accessing the last page-instances (lets say through back button link or >>> otherwise doing a refresh if on the same page)...i still couldnt think >>> of >>> scenarios where the older page-instances (which are being serialized) >>> would >>> come to help...If someone could discuss/point some of those >>> sceanrio/use-cases..that would be helpful..and would be able to better >>> justify the wicket's default behavior of serializing. >>> >>> Thanks and Regards, >>> >>> Farhan. >>> >>> >>> >>> Gwyn wrote: >>> > >>> > Hi, >>> > >>> > It's not hard to do it with Wicket, but I'm fairly sure that >>> > for the typical web-app, the metrics showed that the a re-request to >>> > database wasn't a big issue, whereas the gain in terms of reducing the >>> > session size was, especially where it needs replicating. >>> > >>> > As such, the recommendation is as it is, but it's not >>> > one-size-fits-all, and if you have a large enough percentage of >>> > non-DB-cachable operations in the DB-layer, you can store the results >>> > in the session, etc, without much of a problem. >>> > >>> > It's not going to be so built-in as to be trivial, though, as we want >>> > to make it clear that anyone doing that is going against the flow. >>> > >>> > On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: >>> > sb> Most database expensive operations come from the result of stored >>> > sb> procedures(my current experience at least). A cache solution can >>> be >>> > sb> implemented by caching the method results with spring(in case of >>> using >>> > sb> spring) but is a heavy(difficult) thing to maintain that "cache" >>> per >>> > user - >>> > sb> http session is a nice and easy storage for that-. >>> > >>> > >>> > sb> Eelco Hillenius wrote: >>> >>> >>> >>>> You should use a second level cache to cache objects and queries >>> from >>> >>>> your database; and that's not Wicket's job, Wicket is a Web >>> framework. >>> >>>> >>> >>>> For example, use Hibernate + ehcache. >>> >>> >>> >>> Yep. That way you'll avoid redundancy in caching, and have caching >>> >>> regardless of whatever UI framework you're using. and using e.g. >>> >>> ehcache can do things for you like limit the RAM cache and overflow >>> to >>> >>> disk. Etc. >>> >>> >>> >>> Eelco >>> > >>> > >>> > -- >>> > /Gwyn >>> > >>> > >>> > - >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >>> > For additional commands, e-mail: [EMAIL PROTECTED] >>> > >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586 >>> Sent from the Wicket - User mailing list archive at >>> Nabble.com<http://nabble.com/> >>> . >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13726523 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
its not the lasst access page of a Page. Its the last access page of a page in a pagemap what ever it is PageA or PageB or PageZ On Nov 10, 2007 12:31 AM, mfs <[EMAIL PROTECTED]> wrote: > > In what context are you refering to the back button here...Lets say we > have > two page instances of type "Page-A" through which we landed on "Page-B" > which has a back button on it, now clicking the back butoon should load > the > "Page A" from the pageMap since its last accessed instance of > Page-A...isnt > it ? Why do you say that pressing the back button once will load the page > from the disk... > > > > Johan Compagner wrote: > > > > if you press the back button only once then the page needs to come from > > disk. > > > > So if your users never use the back button then yes you only need to > have > > the last accessed page in the pagemap. > > > > johan > > > > On Nov 9, 2007 10:36 PM, mfs <[EMAIL PROTECTED]> wrote: > > > >> > >> I agree..and i would say its mostly the nature of the applications > which > >> would help determining whether storing the data in the wicket session > >> would > >> be a good idea or not... > >> > >> Further i believe that 99% of the times one just comes to the need of > >> accessing the last page-instances (lets say through back button link or > >> otherwise doing a refresh if on the same page)...i still couldnt think > of > >> scenarios where the older page-instances (which are being serialized) > >> would > >> come to help...If someone could discuss/point some of those > >> sceanrio/use-cases..that would be helpful..and would be able to better > >> justify the wicket's default behavior of serializing. > >> > >> Thanks and Regards, > >> > >> Farhan. > >> > >> > >> > >> Gwyn wrote: > >> > > >> > Hi, > >> > > >> > It's not hard to do it with Wicket, but I'm fairly sure that > >> > for the typical web-app, the metrics showed that the a re-request to > >> > database wasn't a big issue, whereas the gain in terms of reducing > the > >> > session size was, especially where it needs replicating. > >> > > >> > As such, the recommendation is as it is, but it's not > >> > one-size-fits-all, and if you have a large enough percentage of > >> > non-DB-cachable operations in the DB-layer, you can store the results > >> > in the session, etc, without much of a problem. > >> > > >> > It's not going to be so built-in as to be trivial, though, as we want > >> > to make it clear that anyone doing that is going against the flow. > >> > > >> > On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: > >> > sb> Most database expensive operations come from the result of stored > >> > sb> procedures(my current experience at least). A cache solution can > be > >> > sb> implemented by caching the method results with spring(in case of > >> using > >> > sb> spring) but is a heavy(difficult) thing to maintain that "cache" > >> per > >> > user - > >> > sb> http session is a nice and easy storage for that-. > >> > > >> > > >> > sb> Eelco Hillenius wrote: > >> >>> > >> >>>> You should use a second level cache to cache objects and queries > >> from > >> >>>> your database; and that's not Wicket's job, Wicket is a Web > >> framework. > >> >>>> > >> >>>> For example, use Hibernate + ehcache. > >> >>> > >> >>> Yep. That way you'll avoid redundancy in caching, and have caching > >> >>> regardless of whatever UI framework you're using. and using e.g. > >> >>> ehcache can do things for you like limit the RAM cache and overflow > >> to > >> >>> disk. Etc. > >> >>> > >> >>> Eelco > >> > > >> > > >> > -- > >> > /Gwyn > >> > > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586 > >> Sent from the Wicket - User mailing list archive at > >> Nabble.com <http://nabble.com/><http://nabble.com/> > >> . > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13677131 > Sent from the Wicket - User mailing list archive at > Nabble.com<http://nabble.com/> > . > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Disabling serialization/storage of pages in session?
In what context are you refering to the back button here...Lets say we have two page instances of type "Page-A" through which we landed on "Page-B" which has a back button on it, now clicking the back butoon should load the "Page A" from the pageMap since its last accessed instance of Page-A...isnt it ? Why do you say that pressing the back button once will load the page from the disk... Johan Compagner wrote: > > if you press the back button only once then the page needs to come from > disk. > > So if your users never use the back button then yes you only need to have > the last accessed page in the pagemap. > > johan > > On Nov 9, 2007 10:36 PM, mfs <[EMAIL PROTECTED]> wrote: > >> >> I agree..and i would say its mostly the nature of the applications which >> would help determining whether storing the data in the wicket session >> would >> be a good idea or not... >> >> Further i believe that 99% of the times one just comes to the need of >> accessing the last page-instances (lets say through back button link or >> otherwise doing a refresh if on the same page)...i still couldnt think of >> scenarios where the older page-instances (which are being serialized) >> would >> come to help...If someone could discuss/point some of those >> sceanrio/use-cases..that would be helpful..and would be able to better >> justify the wicket's default behavior of serializing. >> >> Thanks and Regards, >> >> Farhan. >> >> >> >> Gwyn wrote: >> > >> > Hi, >> > >> > It's not hard to do it with Wicket, but I'm fairly sure that >> > for the typical web-app, the metrics showed that the a re-request to >> > database wasn't a big issue, whereas the gain in terms of reducing the >> > session size was, especially where it needs replicating. >> > >> > As such, the recommendation is as it is, but it's not >> > one-size-fits-all, and if you have a large enough percentage of >> > non-DB-cachable operations in the DB-layer, you can store the results >> > in the session, etc, without much of a problem. >> > >> > It's not going to be so built-in as to be trivial, though, as we want >> > to make it clear that anyone doing that is going against the flow. >> > >> > On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: >> > sb> Most database expensive operations come from the result of stored >> > sb> procedures(my current experience at least). A cache solution can be >> > sb> implemented by caching the method results with spring(in case of >> using >> > sb> spring) but is a heavy(difficult) thing to maintain that "cache" >> per >> > user - >> > sb> http session is a nice and easy storage for that-. >> > >> > >> > sb> Eelco Hillenius wrote: >> >>> >> >>>> You should use a second level cache to cache objects and queries >> from >> >>>> your database; and that's not Wicket's job, Wicket is a Web >> framework. >> >>>> >> >>>> For example, use Hibernate + ehcache. >> >>> >> >>> Yep. That way you'll avoid redundancy in caching, and have caching >> >>> regardless of whatever UI framework you're using. and using e.g. >> >>> ehcache can do things for you like limit the RAM cache and overflow >> to >> >>> disk. Etc. >> >>> >> >>> Eelco >> > >> > >> > -- >> > /Gwyn >> > >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586 >> Sent from the Wicket - User mailing list archive at >> Nabble.com<http://nabble.com/> >> . >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13677131 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
if you press the back button only once then the page needs to come from disk. So if your users never use the back button then yes you only need to have the last accessed page in the pagemap. johan On Nov 9, 2007 10:36 PM, mfs <[EMAIL PROTECTED]> wrote: > > I agree..and i would say its mostly the nature of the applications which > would help determining whether storing the data in the wicket session > would > be a good idea or not... > > Further i believe that 99% of the times one just comes to the need of > accessing the last page-instances (lets say through back button link or > otherwise doing a refresh if on the same page)...i still couldnt think of > scenarios where the older page-instances (which are being serialized) > would > come to help...If someone could discuss/point some of those > sceanrio/use-cases..that would be helpful..and would be able to better > justify the wicket's default behavior of serializing. > > Thanks and Regards, > > Farhan. > > > > Gwyn wrote: > > > > Hi, > > > > It's not hard to do it with Wicket, but I'm fairly sure that > > for the typical web-app, the metrics showed that the a re-request to > > database wasn't a big issue, whereas the gain in terms of reducing the > > session size was, especially where it needs replicating. > > > > As such, the recommendation is as it is, but it's not > > one-size-fits-all, and if you have a large enough percentage of > > non-DB-cachable operations in the DB-layer, you can store the results > > in the session, etc, without much of a problem. > > > > It's not going to be so built-in as to be trivial, though, as we want > > to make it clear that anyone doing that is going against the flow. > > > > On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: > > sb> Most database expensive operations come from the result of stored > > sb> procedures(my current experience at least). A cache solution can be > > sb> implemented by caching the method results with spring(in case of > using > > sb> spring) but is a heavy(difficult) thing to maintain that "cache" per > > user - > > sb> http session is a nice and easy storage for that-. > > > > > > sb> Eelco Hillenius wrote: > >>> > >>>> You should use a second level cache to cache objects and queries from > >>>> your database; and that's not Wicket's job, Wicket is a Web > framework. > >>>> > >>>> For example, use Hibernate + ehcache. > >>> > >>> Yep. That way you'll avoid redundancy in caching, and have caching > >>> regardless of whatever UI framework you're using. and using e.g. > >>> ehcache can do things for you like limit the RAM cache and overflow to > >>> disk. Etc. > >>> > >>> Eelco > > > > > > -- > > /Gwyn > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586 > Sent from the Wicket - User mailing list archive at > Nabble.com<http://nabble.com/> > . > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Disabling serialization/storage of pages in session?
I agree..and i would say its mostly the nature of the applications which would help determining whether storing the data in the wicket session would be a good idea or not... Further i believe that 99% of the times one just comes to the need of accessing the last page-instances (lets say through back button link or otherwise doing a refresh if on the same page)...i still couldnt think of scenarios where the older page-instances (which are being serialized) would come to help...If someone could discuss/point some of those sceanrio/use-cases..that would be helpful..and would be able to better justify the wicket's default behavior of serializing. Thanks and Regards, Farhan. Gwyn wrote: > > Hi, > > It's not hard to do it with Wicket, but I'm fairly sure that > for the typical web-app, the metrics showed that the a re-request to > database wasn't a big issue, whereas the gain in terms of reducing the > session size was, especially where it needs replicating. > > As such, the recommendation is as it is, but it's not > one-size-fits-all, and if you have a large enough percentage of > non-DB-cachable operations in the DB-layer, you can store the results > in the session, etc, without much of a problem. > > It's not going to be so built-in as to be trivial, though, as we want > to make it clear that anyone doing that is going against the flow. > > On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: > sb> Most database expensive operations come from the result of stored > sb> procedures(my current experience at least). A cache solution can be > sb> implemented by caching the method results with spring(in case of using > sb> spring) but is a heavy(difficult) thing to maintain that "cache" per > user - > sb> http session is a nice and easy storage for that-. > > > sb> Eelco Hillenius wrote: >>> >>>> You should use a second level cache to cache objects and queries from >>>> your database; and that's not Wicket's job, Wicket is a Web framework. >>>> >>>> For example, use Hibernate + ehcache. >>> >>> Yep. That way you'll avoid redundancy in caching, and have caching >>> regardless of whatever UI framework you're using. and using e.g. >>> ehcache can do things for you like limit the RAM cache and overflow to >>> disk. Etc. >>> >>> Eelco > > > -- > /Gwyn > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
serban.balamaci wrote: I am just saying that it may be ok in some cases to keep state on some objects and not have detachable models. I agree. Anything that uses a List of database entities, I tend to put in a detachable model. If I'm merely using a single POJO that was originally pulled from Hibernate, then I don't usually bother, unless it has a bunch of associated objects/collections that are likely to be large. Adding detachable models for absolutely everything is more complex, takes longer to code, and is less obvious; all for very little gain in many situations. Don't prematurely optimize. Do use a profiler. That is all. ;-) Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
I'm not for not considerate caching outside the web layer or a naive aproach to cache everything even if that object changes 10 times a sec. I am just saying that it may be ok in some cases to keep state on some objects and not have detachable models. I'm not saying keep all in session and pay no considerations to separation of concerns. A nice design surelly is where the cache stands beetween the web and the database layer, but we may have the case where we use stored procedures intensively and the result may take a long time to return but that result may well be not be heavy(i guess that can be the case with stored procedures). We always have to think of the impact of presenting stale data. Johan Compagner wrote: > > Also caching data inside a session and having those object over multiply > request > gives in hibernate always errors like LazyInitalizationException or > Transient/StaleObjectException > > Holding on to data in sessions is really a bad idea because you dont know > when they come back > if you have a session time out of a few hours, and people open pages and > then do nothing for 15-30minutes > then a huge page is kept in memory all the time. So if you keep growing > users then you will hit > memory problems very soon. Also if you constantly cache objects are those > objects not changing between > request by others? How do avoid state objects? > > User A changed an object and tells that to User B that wants to work with > it. Then User B hits > refresh 10 times but still sees the old value.. > > johan > > > > On Nov 9, 2007 9:13 AM, serban.balamaci <[EMAIL PROTECTED]> wrote: > >> >> Why is everybody pointing out not to have database data inside the page? >> Many >> times retrieving the data from the database could be the slowest thing >> and >> having that sort of cache is one nice thing in my opinion. Is it not much >> better to have data in the session? I understand that it will be a >> negative >> point in clustering for session replication, but that might not be such a >> drawback. The state could be replicated to the other server >> asyncroniously >> after the request was presented back to the user so he sees no >> degradation >> in performance, or better use sticky load balance and not have session >> replication. Also you might need to sacrifice the availability of the >> back >> button, although by keeping multiple versions of the page that can be >> avoided? Are there other negatives?. >> >> >> Johan Compagner wrote: >> > >> > Use detachable models.. Never keep database data live inside your >> models >> > just store the minimal state so that you can construct it again. >> > >> > The DiskStore is for the backbutton and the PageMap (thats in the >> session) >> > is for the >> > current page. And as long as that page is statefull you have to store >> it >> > in >> > the session >> > There is no other way because that wouldn't make any sense. >> > >> > johan >> > >> > On Nov 8, 2007 8:22 PM, mfs <[EMAIL PROTECTED]> wrote: >> > >> >> >> >> Well that was just hypothetically speaking..what i meant was it would >> >> have >> >> loads of data loaded in it..so it was that scenario where i was >> wondering >> >> that we shouldnt store the state of each page. >> >> Yes as you pointed out using detachable models can certainly be one to >> >> way >> >> to go..but at the same time since i am sort of presenting my company >> with >> >> all the features, i want to be prepared with answers and would want to >> >> know >> >> as much as i can.. >> >> >> >> So with what i understand the page serialization can be disabled by >> >> providing a dummy page-store but the storage of pages in the pageMap >> and >> >> hence in the current active session is something which is implicit and >> >> not >> >> something we can avoid.. >> >> >> >> >> >> >> >> Eelco Hillenius wrote: >> >> > >> >> >> Now there would be certain use-cases/pages in our application which >> >> would >> >> >> have alot of data in it (lets say in mbs), and in that scenario >> >> storing >> >> >> the >> >> >> entire model-data/components would probably bring in too much of a >> >> load >> >> >> on >> >> >> the system (in my
Re: Disabling serialization/storage of pages in session?
Hi, It's not hard to do it with Wicket, but I'm fairly sure that for the typical web-app, the metrics showed that the a re-request to database wasn't a big issue, whereas the gain in terms of reducing the session size was, especially where it needs replicating. As such, the recommendation is as it is, but it's not one-size-fits-all, and if you have a large enough percentage of non-DB-cachable operations in the DB-layer, you can store the results in the session, etc, without much of a problem. It's not going to be so built-in as to be trivial, though, as we want to make it clear that anyone doing that is going against the flow. On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: sb> Most database expensive operations come from the result of stored sb> procedures(my current experience at least). A cache solution can be sb> implemented by caching the method results with spring(in case of using sb> spring) but is a heavy(difficult) thing to maintain that "cache" per user - sb> http session is a nice and easy storage for that-. sb> Eelco Hillenius wrote: >> >>> You should use a second level cache to cache objects and queries from >>> your database; and that's not Wicket's job, Wicket is a Web framework. >>> >>> For example, use Hibernate + ehcache. >> >> Yep. That way you'll avoid redundancy in caching, and have caching >> regardless of whatever UI framework you're using. and using e.g. >> ehcache can do things for you like limit the RAM cache and overflow to >> disk. Etc. >> >> Eelco -- /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
Also caching data inside a session and having those object over multiply request gives in hibernate always errors like LazyInitalizationException or Transient/StaleObjectException Holding on to data in sessions is really a bad idea because you dont know when they come back if you have a session time out of a few hours, and people open pages and then do nothing for 15-30minutes then a huge page is kept in memory all the time. So if you keep growing users then you will hit memory problems very soon. Also if you constantly cache objects are those objects not changing between request by others? How do avoid state objects? User A changed an object and tells that to User B that wants to work with it. Then User B hits refresh 10 times but still sees the old value.. johan On Nov 9, 2007 9:13 AM, serban.balamaci <[EMAIL PROTECTED]> wrote: > > Why is everybody pointing out not to have database data inside the page? > Many > times retrieving the data from the database could be the slowest thing and > having that sort of cache is one nice thing in my opinion. Is it not much > better to have data in the session? I understand that it will be a > negative > point in clustering for session replication, but that might not be such a > drawback. The state could be replicated to the other server asyncroniously > after the request was presented back to the user so he sees no degradation > in performance, or better use sticky load balance and not have session > replication. Also you might need to sacrifice the availability of the back > button, although by keeping multiple versions of the page that can be > avoided? Are there other negatives?. > > > Johan Compagner wrote: > > > > Use detachable models.. Never keep database data live inside your models > > just store the minimal state so that you can construct it again. > > > > The DiskStore is for the backbutton and the PageMap (thats in the > session) > > is for the > > current page. And as long as that page is statefull you have to store it > > in > > the session > > There is no other way because that wouldn't make any sense. > > > > johan > > > > On Nov 8, 2007 8:22 PM, mfs <[EMAIL PROTECTED]> wrote: > > > >> > >> Well that was just hypothetically speaking..what i meant was it would > >> have > >> loads of data loaded in it..so it was that scenario where i was > wondering > >> that we shouldnt store the state of each page. > >> Yes as you pointed out using detachable models can certainly be one to > >> way > >> to go..but at the same time since i am sort of presenting my company > with > >> all the features, i want to be prepared with answers and would want to > >> know > >> as much as i can.. > >> > >> So with what i understand the page serialization can be disabled by > >> providing a dummy page-store but the storage of pages in the pageMap > and > >> hence in the current active session is something which is implicit and > >> not > >> something we can avoid.. > >> > >> > >> > >> Eelco Hillenius wrote: > >> > > >> >> Now there would be certain use-cases/pages in our application which > >> would > >> >> have alot of data in it (lets say in mbs), and in that scenario > >> storing > >> >> the > >> >> entire model-data/components would probably bring in too much of a > >> load > >> >> on > >> >> the system (in my opinion...given high volume of users..) so with > that > >> >> may > >> >> be we would not want to store the pages in pageMap at all (which in > >> turn > >> >> is > >> >> stored in the session). > >> > > >> > But I hope you're not storing MBs of data in your pages?! Users will > >> > also get pages served that are MBs large? Note that you don't have to > >> > keep anything in memory if you work with detachable models. > >> > > >> > Eelco > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13653854 > >> Sent from the Wicket - User mailing list archive at > >> Nabble.com <http://nabble.com/><http://nabble.com/> > >> . > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13662918 > Sent from the Wicket - User mailing list archive at > Nabble.com<http://nabble.com/> > . > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Disabling serialization/storage of pages in session?
Most database expensive operations come from the result of stored procedures(my current experience at least). A cache solution can be implemented by caching the method results with spring(in case of using spring) but is a heavy(difficult) thing to maintain that "cache" per user - http session is a nice and easy storage for that-. Eelco Hillenius wrote: > >> You should use a second level cache to cache objects and queries from >> your database; and that's not Wicket's job, Wicket is a Web framework. >> >> For example, use Hibernate + ehcache. > > Yep. That way you'll avoid redundancy in caching, and have caching > regardless of whatever UI framework you're using. and using e.g. > ehcache can do things for you like limit the RAM cache and overflow to > disk. Etc. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13663495 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
> You should use a second level cache to cache objects and queries from > your database; and that's not Wicket's job, Wicket is a Web framework. > > For example, use Hibernate + ehcache. Yep. That way you'll avoid redundancy in caching, and have caching regardless of whatever UI framework you're using. and using e.g. ehcache can do things for you like limit the RAM cache and overflow to disk. Etc. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
Hi, You should use a second level cache to cache objects and queries from your database; and that's not Wicket's job, Wicket is a Web framework. For example, use Hibernate + ehcache. Regards, Sebastiaan serban.balamaci wrote: Why is everybody pointing out not to have database data inside the page? Many times retrieving the data from the database could be the slowest thing and having that sort of cache is one nice thing in my opinion. Is it not much better to have data in the session? I understand that it will be a negative point in clustering for session replication, but that might not be such a drawback. The state could be replicated to the other server asyncroniously after the request was presented back to the user so he sees no degradation in performance, or better use sticky load balance and not have session replication. Also you might need to sacrifice the availability of the back button, although by keeping multiple versions of the page that can be avoided? Are there other negatives?. Johan Compagner wrote: Use detachable models.. Never keep database data live inside your models just store the minimal state so that you can construct it again. The DiskStore is for the backbutton and the PageMap (thats in the session) is for the current page. And as long as that page is statefull you have to store it in the session There is no other way because that wouldn't make any sense. johan On Nov 8, 2007 8:22 PM, mfs <[EMAIL PROTECTED]> wrote: Well that was just hypothetically speaking..what i meant was it would have loads of data loaded in it..so it was that scenario where i was wondering that we shouldnt store the state of each page. Yes as you pointed out using detachable models can certainly be one to way to go..but at the same time since i am sort of presenting my company with all the features, i want to be prepared with answers and would want to know as much as i can.. So with what i understand the page serialization can be disabled by providing a dummy page-store but the storage of pages in the pageMap and hence in the current active session is something which is implicit and not something we can avoid.. Eelco Hillenius wrote: Now there would be certain use-cases/pages in our application which would have alot of data in it (lets say in mbs), and in that scenario storing the entire model-data/components would probably bring in too much of a load on the system (in my opinion...given high volume of users..) so with that may be we would not want to store the pages in pageMap at all (which in turn is stored in the session). But I hope you're not storing MBs of data in your pages?! Users will also get pages served that are MBs large? Note that you don't have to keep anything in memory if you work with detachable models. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13653854 Sent from the Wicket - User mailing list archive at Nabble.com<http://nabble.com/> . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: Disabling serialization/storage of pages in session?
Why is everybody pointing out not to have database data inside the page? Many times retrieving the data from the database could be the slowest thing and having that sort of cache is one nice thing in my opinion. Is it not much better to have data in the session? I understand that it will be a negative point in clustering for session replication, but that might not be such a drawback. The state could be replicated to the other server asyncroniously after the request was presented back to the user so he sees no degradation in performance, or better use sticky load balance and not have session replication. Also you might need to sacrifice the availability of the back button, although by keeping multiple versions of the page that can be avoided? Are there other negatives?. Johan Compagner wrote: > > Use detachable models.. Never keep database data live inside your models > just store the minimal state so that you can construct it again. > > The DiskStore is for the backbutton and the PageMap (thats in the session) > is for the > current page. And as long as that page is statefull you have to store it > in > the session > There is no other way because that wouldn't make any sense. > > johan > > On Nov 8, 2007 8:22 PM, mfs <[EMAIL PROTECTED]> wrote: > >> >> Well that was just hypothetically speaking..what i meant was it would >> have >> loads of data loaded in it..so it was that scenario where i was wondering >> that we shouldnt store the state of each page. >> Yes as you pointed out using detachable models can certainly be one to >> way >> to go..but at the same time since i am sort of presenting my company with >> all the features, i want to be prepared with answers and would want to >> know >> as much as i can.. >> >> So with what i understand the page serialization can be disabled by >> providing a dummy page-store but the storage of pages in the pageMap and >> hence in the current active session is something which is implicit and >> not >> something we can avoid.. >> >> >> >> Eelco Hillenius wrote: >> > >> >> Now there would be certain use-cases/pages in our application which >> would >> >> have alot of data in it (lets say in mbs), and in that scenario >> storing >> >> the >> >> entire model-data/components would probably bring in too much of a >> load >> >> on >> >> the system (in my opinion...given high volume of users..) so with that >> >> may >> >> be we would not want to store the pages in pageMap at all (which in >> turn >> >> is >> >> stored in the session). >> > >> > But I hope you're not storing MBs of data in your pages?! Users will >> > also get pages served that are MBs large? Note that you don't have to >> > keep anything in memory if you work with detachable models. >> > >> > Eelco >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13653854 >> Sent from the Wicket - User mailing list archive at >> Nabble.com<http://nabble.com/> >> . >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13662918 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
Use detachable models.. Never keep database data live inside your models just store the minimal state so that you can construct it again. The DiskStore is for the backbutton and the PageMap (thats in the session) is for the current page. And as long as that page is statefull you have to store it in the session There is no other way because that wouldn't make any sense. johan On Nov 8, 2007 8:22 PM, mfs <[EMAIL PROTECTED]> wrote: > > Well that was just hypothetically speaking..what i meant was it would have > loads of data loaded in it..so it was that scenario where i was wondering > that we shouldnt store the state of each page. > Yes as you pointed out using detachable models can certainly be one to way > to go..but at the same time since i am sort of presenting my company with > all the features, i want to be prepared with answers and would want to > know > as much as i can.. > > So with what i understand the page serialization can be disabled by > providing a dummy page-store but the storage of pages in the pageMap and > hence in the current active session is something which is implicit and not > something we can avoid.. > > > > Eelco Hillenius wrote: > > > >> Now there would be certain use-cases/pages in our application which > would > >> have alot of data in it (lets say in mbs), and in that scenario storing > >> the > >> entire model-data/components would probably bring in too much of a load > >> on > >> the system (in my opinion...given high volume of users..) so with that > >> may > >> be we would not want to store the pages in pageMap at all (which in > turn > >> is > >> stored in the session). > > > > But I hope you're not storing MBs of data in your pages?! Users will > > also get pages served that are MBs large? Note that you don't have to > > keep anything in memory if you work with detachable models. > > > > Eelco > > > > ----------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13653854 > Sent from the Wicket - User mailing list archive at > Nabble.com<http://nabble.com/> > . > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Disabling serialization/storage of pages in session?
> Well that was just hypothetically speaking..what i meant was it would have > loads of data loaded in it..so it was that scenario where i was wondering > that we shouldnt store the state of each page. > Yes as you pointed out using detachable models can certainly be one to way > to go..but at the same time since i am sort of presenting my company with > all the features, i want to be prepared with answers and would want to know > as much as i can.. But it is really premature optimization to worry about this now. If you are worried about this, the best thing you can do is write an actual page (or a couple) and load test it and see how it behaves. Much better than wild guessing what you think might happen :-) > So with what i understand the page serialization can be disabled by > providing a dummy page-store but the storage of pages in the pageMap and > hence in the current active session is something which is implicit and not > something we can avoid.. Only the current page yes. Unless you work with stateless pages, which don't get stored it the first place. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
Well that was just hypothetically speaking..what i meant was it would have loads of data loaded in it..so it was that scenario where i was wondering that we shouldnt store the state of each page. Yes as you pointed out using detachable models can certainly be one to way to go..but at the same time since i am sort of presenting my company with all the features, i want to be prepared with answers and would want to know as much as i can.. So with what i understand the page serialization can be disabled by providing a dummy page-store but the storage of pages in the pageMap and hence in the current active session is something which is implicit and not something we can avoid.. Eelco Hillenius wrote: > >> Now there would be certain use-cases/pages in our application which would >> have alot of data in it (lets say in mbs), and in that scenario storing >> the >> entire model-data/components would probably bring in too much of a load >> on >> the system (in my opinion...given high volume of users..) so with that >> may >> be we would not want to store the pages in pageMap at all (which in turn >> is >> stored in the session). > > But I hope you're not storing MBs of data in your pages?! Users will > also get pages served that are MBs large? Note that you don't have to > keep anything in memory if you work with detachable models. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13653854 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
> Now there would be certain use-cases/pages in our application which would > have alot of data in it (lets say in mbs), and in that scenario storing the > entire model-data/components would probably bring in too much of a load on > the system (in my opinion...given high volume of users..) so with that may > be we would not want to store the pages in pageMap at all (which in turn is > stored in the session). But I hope you're not storing MBs of data in your pages?! Users will also get pages served that are MBs large? Note that you don't have to keep anything in memory if you work with detachable models. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
Basically we are still researching wicket and figuring out if that would be the desired framework for us (so far it does look promising)..and in that context we are exploring all the different scenarios/use-cases/possibilities... Now there would be certain use-cases/pages in our application which would have alot of data in it (lets say in mbs), and in that scenario storing the entire model-data/components would probably bring in too much of a load on the system (in my opinion...given high volume of users..) so with that may be we would not want to store the pages in pageMap at all (which in turn is stored in the session)..i do understand the back button scenario where we might think that yeah "we need to have that previous state" ..but lets say what if we dont have that back button as a link (offcouse we cant avoid the browser-back button where he would be loaded with catch-ed page) So its in the above context i had asked about disabling of page/pageMap storage in session altogether (not just the serialization of old pages) Johan Compagner wrote: > > like eelco said if you don't want to serialize and store on disk, create a > filestore that does nothing > (or holds a few pages for per session in mem for backbutton) > > But what do you mean with disable the storage of pages in a session? > You don't want to store a statefull page at all in the pagemap (and thats > then in the session)? > Because thats really no use at all then because the page in the browser is > useless > If you don't want pages in the session and on disk. Then make them fully > stateless (see stateless link and form) > > johan > > > > > On Nov 8, 2007 12:08 AM, mfs <[EMAIL PROTECTED]> wrote: > >> >> Guys, >> >> If need be, can we disable altogether the storage of pages (in the form >> of >> a >> pageMap) in session, similarly on the disk ? >> >> Thanks and Regards, >> >> Farhan. >> -- >> View this message in context: >> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13638150 >> Sent from the Wicket - User mailing list archive at >> Nabble.com<http://nabble.com/> >> . >> >> >> --------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13653100 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling serialization/storage of pages in session?
like eelco said if you don't want to serialize and store on disk, create a filestore that does nothing (or holds a few pages for per session in mem for backbutton) But what do you mean with disable the storage of pages in a session? You don't want to store a statefull page at all in the pagemap (and thats then in the session)? Because thats really no use at all then because the page in the browser is useless If you don't want pages in the session and on disk. Then make them fully stateless (see stateless link and form) johan On Nov 8, 2007 12:08 AM, mfs <[EMAIL PROTECTED]> wrote: > > Guys, > > If need be, can we disable altogether the storage of pages (in the form of > a > pageMap) in session, similarly on the disk ? > > Thanks and Regards, > > Farhan. > -- > View this message in context: > http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13638150 > Sent from the Wicket - User mailing list archive at > Nabble.com<http://nabble.com/> > . > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Disabling serialization/storage of pages in session?
> If need be, can we disable altogether the storage of pages (in the form of a > pageMap) in session, similarly on the disk ? Yep. One easy way to achieve this is to provide a dummy page store. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Disabling serialization/storage of pages in session?
Guys, If need be, can we disable altogether the storage of pages (in the form of a pageMap) in session, similarly on the disk ? Thanks and Regards, Farhan. -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13638150 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
