On Dec 12, 2006, at 15:25 , Andrus Adamchik wrote:
On commit lock spans the following chain of operations: update query preparation -> DB commit -> cache postprocessing. Maybe we can reduce the scope to just the last step, resulting in some fuzziness in the baseline snapshot versions.
I hope the fuzziness will be ignorable. A object query from one thread may give an old result while another thread is doing "query preparation" or "DB commit". If a database commit is an atomic operation, returning old snapshot before the commit are finished should probably be the correct thing to do?
There will be a short periode of incorrect state between when db commit completes and the DataRowStore are locked for "cache postprocessing", but this is in different threads and should be (as DC are not threadsafe) in different DataContexts. If a user need this level over synchronization between thread operations, he should probably do his own synchronization?
Are there any brave souls with high volume update-heavy sites to try this modification in production to see how much damage it causes? Tore, do you want to try it in your app? I am asking cause it may take me a while to do thorough stress testing, although just moving the lock is trivial.
We are not that update-heavy and I do not think this issue is critical enough for us to test a fix in the production environment now. Sorry. However - my new quad MacPro are quite good at finding threading issues :)
- Tore.
