Slide 2.1 tries to fix this with two measures:
(1) Sequences have been introduced to deliver a unique id for collections created in the history folder. This circumvents conflicts caused by already created collections in concurrent versioning requests
(2) Exclusive locks that only live for the time of a transaction and lock all folders that are modified. As the sequence of changes in a put request is fixed, this should circumvent all deadlocks with ordinary put requests
There has been an OutOfMemory error in the latest CVS head, but this should have been fixed by now. Also, default timeouts in the Domain.xml have been a bit too tight. I have increased them to 120 seconds.
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.
I will however, add a switch that allows Slide to never deadlock. You will be surprised how simple and crappy it will be. More to come...
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
