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.
This archive was generated by hypermail 2.0.0 : Wed Dec 13 2006 - 04:41:24 EST