yeah, even my pre-emptive lock claiming idea would require some thinking about versioning. what happens to all the versioning information recorded by the pre-empted thread? we'd need a transacted commit on that.
actually, if you think about database technologies here, one way to get better locking behavior might be to refactor all the component mutation code in wicket so it's all optimistically locked, isolated and transacted. threads could freely do mutations, but those changes would be magically invisible to other threads. then at the end of the request, versioning would try to commit the changes made to the hierarchy. if the transaction failed due to optimistic locking (writer contention to the component hierarchy), the thread could actually discard its results and re-do the request on the new hierarchy before returning results. all of the usual problems with reader/writer multithreading come into play here of course... component mutating threads (writers) could potentially starve and so forth... but it's something worth thinking about anyway. Eelco Hillenius wrote: > >> in general the problem with wicket is that it has a stateful >> and >> mutable component model. if one thread is busy recursively rendering >> component >> A and another thread decides to remove it in the middle of that process, >> what then? >> to allow the two threads to both work on the component model, you can >> either >> block >> and serialize the threads (current approach) or you can copy the at least >> part of the >> model (and any naive approach here would be totally prohibitive). since >> a >> wicket >> ajax request to do a partial render is often localized to a particular >> piece >> of the model, >> it might be possible to do some tree-granularity lock splitting, but this >> is >> a really >> major piece of work and will require at least a lot of discussion and >> another release >> cycle after 1.3 to address. > > Even if we would be able to provide a thread safe programming model by > doing lots of magic under the hood, we would still have a problem > determining versions. But sure, we should try to keep pushing the > envelope where we can. > > Eelco > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > > -- View this message in context: http://www.nabble.com/Multiple-asynchronous-Ajax-calls---once-again-tf4034837.html#a11475099 Sent from the Wicket - User mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
