On 7/6/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
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.
this sounds great for code we control, but what about user code? if the user
calls a method from onclick that invocation needs to be threadsafe - it
might be mutating fields on that component.
-igor
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
-------------------------------------------------------------------------
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
