I agree with Eelco. We had a lot of problems in our project with pages
getting expired due to too lax locking. I'm not running to open up
that can of worms again by relaxing the session locks.
On the other hand, we have experienced hanging sessions as well. I
haven't looked into it, as it doesn't seem to happen on a regular
basis so debugging it would be a bit like predicting the soccer world
cup champion of 2014.
Setting a timeout on a request is something worth considering. A user
is typically not willing to wait 10 minutes for the welcome page to
show up :). I do think it is hard to set a limit from a framework
perspective. Default, which doesn't alter current behavior, could be
to use the session timeout.
Martijn
On 6/21/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> 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
>
--
Download Wicket 1.2 now! Write Ajax applications without touching JavaScript!
-- http://wicketframework.org
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
