If there was something like RequestCycle.lockSession() RequestCycle.unlockSession()
where in my onClock handler I could call RequestCycle.get().unlockSession() --do-my-stuff-and-don't-touch-the-session! RequestCycle.get().lockSession() I know this adds responsibility to the developer, but this is only for corner cases. -Matej Matej Knopp wrote: > Sorry, i'm lost. How is overriding getlock() supposed to help me? I need > to lock the session, but not for the whole request. Just for a part > before the db call and the part after. > > -Matej > > Igor Vaynberg wrote: >> in that case we sort of already have a mechanism for that, request >> target has a getlock() which you can override and return something other >> then session, just need a way to encode a url so it is resolved to your >> own target >> >> -Igor >> >> >> >> >> On 6/21/06, *Matej Knopp* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> >> wrote: >> >> Well, it would be your responsibility not to touch application or >> session if the mutex is unlocked. This is not something an average joe >> would do in every link handler. You would do that only right before a >> long db operation and lock it right after it. >> >> I'm not looking for perfect solution. I'm looking for one that works. A >> solution when the application stops responding until session expires is >> not perfect either. >> >> -Matej >> >> Igor Vaynberg wrote: >> > but you wouldnt want to unlock the mutex, thats kinda the whole >> point! >> > what if both pages access session object? or application object? >> now you >> > have to start worrying about concurrency on those. the advantage of >> > letting only one page request through at a time is that users >> dont have >> > to think about concurrency, if we dont do that the programming model >> > becomes much more complicated. it has its draw backs for sure, but i >> > dont think there is a perfect solution here. >> > >> > -Igor >> > >> > >> > >> > On 6/21/06, *Matej Knopp* <[EMAIL PROTECTED] <mailto:[EMAIL >> PROTECTED]> >> <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: >> > >> > Igor Vaynberg wrote: >> > > not unless all page targets return the same mutex instance :) >> > The mutex would be stored in session of course :) >> > > >> > > the point is that only a single page is processed at a time >> > because of >> > > pagemap, etc. although i dont really know if the pagemap is >> > affected all >> > > that much in 2.0. >> > > >> > > but even then, lets say i double click a link really fast, >> i get two >> > > different instances of pagetarget that are going to do >> processing >> > on the >> > > same page instance, so once again both of those page >> targets have to >> > > return the same mutex instance. dont know how we are going >> to do >> > that or >> > > if it will be simpler/better then locking session. >> > I don't think it would be simpler. But it would be better in >> a way that >> > if you have an action that takes very long, you can "unlock" >> the mutex >> > in you link handler, let other requests process, and after >> you are >> > done, >> > you lock the session again. >> > > >> > > the thing about the db locking up is that it should have some >> > sort of a >> > > timeout that throws an error, and the sync block should >> then be >> > broken. >> > > that doesnt happen? sounds like more of a fault in your app? >> > maybe we >> > > should build a timeout for our sync block. >> > Well, the db can either lock up, or it really takes that long >> to get the >> > data (complicated statistics, reports, etc). In the meanwhile >> user would >> > like to work with the rest of the application but he can't. >> > >> > -Matej >> > > >> > > -Igor >> > > >> > > >> > > On 6/21/06, *Matej Knopp* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL >> PROTECTED]>> >> > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>> wrote: >> > > >> > > Hi, >> > > >> > > we have a problem with session locking. Sometimes, the >> underlying >> > > database just hangs and the response is not processed >> > properly. The >> > > problem is that HttpSession remains locked. >> > > >> > > Wouldn't it be possible to replace the current locking >> mechanism >> > > ( synchronized(lock) { doEverything() } ) >> > > >> > > with something that would behave more like a mutex? >> > > >> > > e.g. >> > > >> > > Mutext mutex = getRequestTarget().getMutex(); >> > > >> > > mutex.lock(); >> > > processRequest(); >> > > mutex.unlock (); >> > > >> > > and the code running the operation could look like >> > > >> > > >> RequestCycle().get().getReqeustTarget().getMutex().unlock(); >> > > doMySloooowOperation(); >> > > >> RequestCycle().get().getReqeustTarget().getMutex().lock(); >> > > >> > > -Matej >> > > >> > > >> > > _______________________________________________ >> > > Wicket-develop mailing list >> > > Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net> >> > <mailto:Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net>> >> > > <mailto: Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net> >> > <mailto:Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net>>> >> > > >> https://lists.sourceforge.net/lists/listinfo/wicket-develop >> > < https://lists.sourceforge.net/lists/listinfo/wicket-develop> >> > > >> > > >> > > >> > > >> > >> ------------------------------------------------------------------------ >> >> > > >> > > _______________________________________________ >> > > Wicket-develop mailing list >> > > Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net> >> > <mailto:Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net>> >> > > >> https://lists.sourceforge.net/lists/listinfo/wicket-develop >> <https://lists.sourceforge.net/lists/listinfo/wicket-develop> >> > >> > >> > >> > _______________________________________________ >> > Wicket-develop mailing list >> > Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net> >> > <mailto:Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net>> >> > https://lists.sourceforge.net/lists/listinfo/wicket-develop >> <https://lists.sourceforge.net/lists/listinfo/wicket-develop> >> > <https://lists.sourceforge.net/lists/listinfo/wicket-develop> >> > >> > >> > >> > >> ------------------------------------------------------------------------ >> >> > >> > _______________________________________________ >> > Wicket-develop mailing list >> > Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net> >> > https://lists.sourceforge.net/lists/listinfo/wicket-develop >> >> >> >> _______________________________________________ >> Wicket-develop mailing list >> Wicket-develop@lists.sourceforge.net >> <mailto:Wicket-develop@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/wicket-develop >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Wicket-develop mailing list >> Wicket-develop@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
