Re: Concurrent upload error: Status Quo

[Warwick Burrows <wa...@e2open.com>]

Hi Oliver,
 
I have some questions regarding a post you made in late July concerning
causes for deadlocks in 2.0 and 2.1M1. eg.
 
>> Unfortunately, using the latest CVS version and the file store there
still are sources for deadlocks, although they
>> should occur less frequently, especially when auto-versioning is used.
The main reason for this is security checking.
>> Because of this it would be a great improvement to cache calculated
securtiy setting for resources. Let's see what >> 2.2 or 3.0 will bring. If
you use other RDBMS try to set a low isolation level to reduce the risk of
deadlocks. 
>> READ COMMITTED might be a good compromise.
>>
>> When using the file store and have lots of concurrent requests it might
be better to switch off "defer saving" as write
>> locks will only be claimed very late in a transaction, also increasing
the risk of deadlocks.
 
What I get from this post is that to avoid deadlocks I should:
 
1) auto versioning causes deadlocks to occur more often so I should turn
auto-versioning off.
2) set the isolation level of stores that use a DB to be READ COMMITTED
3) for the tx filestore set the "defer saving" parameter to "false" to force
locks to be claimed earlier in the transaction.
 
Is this correct?  Will the 2.1 beta fix the deadlock problems or will I need
to do the same steps for it when I deploy it?
 
Thanks,
Warwick