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
