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 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] >> >> > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13663980 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
