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
