Yeah, I've been thinking about this. Should be quite elegant using closure (anonymous class). But still, the problem with big session lock will raise, sooner or later :)
-Matej Igor Vaynberg wrote: > not really a solution, but something that might help, spin off the > thread in onclick and wait for it to finish for some number of > milliseconds - that should at least give you some control over a timeout. > > -Igor > > > On 6/21/06, *Matej Knopp* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > I don't know if it can be considered a deadlock, but basicaly, if (for > any reason) a request doesn't complete (db problem, etc), no further > requests from the same session can be processed. > > Now maybe if you have perfect business objects that's not an issue, but > in our current project we depend on third party business objects and > sometimes they behave very funny. > > The "hack" with unlocking session would solve this, but I must admit, it > would be still a hack. But I can't think of any other solution except > for doing the operation in separate thread, which should be doable but > it would complicate the thing quite a lot. > > I'm I the only one with this issue? > > -Matej > > Eelco Hillenius wrote: > > I think providing unlocking functionality is not the way to go. You > > basically just provide a hack opportunity if you do that, and that's > > not what a framework should do. I'm not really getting the problem at > > this point, but if we have a possible deadlock in our request > > handling, that's obviously a bug. If we have not, it's not a bug, and > > any 'fixes' we do should be geared towards clean improvements, not > > workarounds. > > > > Eelco > > > > > > On 6/21/06, Matej Knopp < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > >> I'm also curious what other devs would say. New thread could > solve this > >> but it's not the solution i'm looking for. > >> > >> I think the locking should be more flexible then just > >> synchronized(myBFLock) { > >> processTheWholeRequest(); > >> } > >> even if it needs additional refactor. > >> > >> (Maybe RequestTarget#lock and RequestTarget#unlock?) > >> > >> But that's my humble opinion only. > >> > >> -Matej > >> > >> Igor Vaynberg wrote: > >>> the page targets are too flexible to support something like > this because > >>> they do not lock on session specifically - the implementation just > >>> happens to do that now. and this would also require us to > completely > >>> change how we do locking/refactor requesttargets possibly, etc. > >>> > >>> we should run this past other core devels and see their opinions. > >>> > >>> personally, if i knew i had a long running process i would spin > off a > >>> new thread, do it there, then notify the user when it is > complete. i > >>> know that is not always doable, just a suggestion. > >>> > >>> -Igor > >>> > >>> > >>> On 6/21/06, *Matej Knopp* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>> wrote: > >>> > >>> 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]> > >>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >>> <mailto:[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]>> <mailto: > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>> > >>> >> <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > >>> <mailto:[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]>> > > >>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > >>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>> > >>> >> > <mailto: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL > PROTECTED]>> > >>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> > >>> >> <mailto:[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>>> > >>> >> > <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 > <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> > >>> <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 > <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 > <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>> > >>> >> <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 > <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> > >>> >> > <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>> > >>> >> <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 > <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 > <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> > >>> <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 > >>> >> > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> 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 > >>> >> > >>> >> > >>> >> > >>> >> > >>> > ------------------------------------------------------------------------ > >>> > >>> >> > >>> >> _______________________________________________ > >>> >> 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 > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > 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 > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ > > >>> > >>> _______________________________________________ > >>> 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 > <mailto:Wicket-develop@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat > certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642> > _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > <mailto:Wicket-develop@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > ------------------------------------------------------------------------ > > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
