Oh, sorry, you mentioned one more step to minimize deadlock problems: 4) disable Slide internal security checks via the slide.properties file.
Thanks, Warwick -----Original Message----- From: Warwick Burrows Sent: Monday, August 02, 2004 3:44 PM To: 'Slide User Group ([EMAIL PROTECTED])' Subject: Re: Concurrent upload error: Status Quo 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
