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]> 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]>> 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>
>     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

Reply via email to