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