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
> > >> > > [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]>>>>
> > >> > >
> > >> 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
> > >> > > [email protected]
> > <mailto:[email protected]>
> > >> <mailto:[email protected]
> > <mailto:[email protected]>>
> > >> > <mailto: [email protected]
> > <mailto:[email protected]>
> > >> <mailto:[email protected]
> > <mailto:[email protected]>>>
> > >> > >
> > >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >> <https://lists.sourceforge.net/lists/listinfo/wicket-develop>
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > Wicket-develop mailing list
> > >> > [email protected]
> > <mailto:[email protected]>
> > >> <mailto:[email protected]
> > <mailto:[email protected]>>
> > >> > <mailto:[email protected]
> > <mailto:[email protected]>
> > >> <mailto:[email protected]
> > <mailto:[email protected]>>>
> > >> >
> > 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
> > >> > [email protected]
> > <mailto:[email protected]>
> > >> <mailto:[email protected]
> > <mailto:[email protected]>>
> > >> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Wicket-develop mailing list
> > >> [email protected]
> > <mailto:[email protected]>
> > >> <mailto:[email protected]
> > <mailto:[email protected]>>
> > >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >>
> > >>
> > >>
> > >>
> > ------------------------------------------------------------------------
> >
> > >>
> > >> _______________________________________________
> > >> Wicket-develop mailing list
> > >> [email protected]
> > <mailto:[email protected]>
> > >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >
> > >
> > >
> > > _______________________________________________
> > > Wicket-develop mailing list
> > > [email protected]
> > <mailto:[email protected]>
> > > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > <https://lists.sourceforge.net/lists/listinfo/wicket-develop>
> > >
> >
> >
> >
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> > <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
>
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
