We could consider building in a time out for the lock itself. That
timeout should be configurable. I agree that being able to hang up the
session is definitively not what we should want.
Eelco
On 6/21/06, Matej Knopp <[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]> 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]>>
> >>> 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]>>> 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]>>>> 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]>>>>> 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>>>>
> >>> >> > >
> >>> >> 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
> >>> >> <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
> >>> >> < 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>>
> >>> >> > 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
> >>> <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
> >
>
>
> 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
