-Igor
On 6/21/06, Matej Knopp <[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]>> 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]>>> 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>>
> > 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
> <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
> 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
