Hi Thomas, the storage engine in 3.1 and before that uses collection-specific read-write locks. The locks are acquired within transactions but also other standalone data-modification and retrieval operations (such as insert, remove, update, replace, truncate, document) and AQL queries. With 3.2 we will introduce a second storage engine, which won't have these read-write locks, so reads will never block any writes (nor readers).
Best regards Jan Am Donnerstag, 6. April 2017 06:02:00 UTC+2 schrieb Thomas Weiss: > > Hi Jan, > > Considering your answer again, I'm wondering if all queries, even > read-only ones, lock the collections they access? I thought that only > transactions locked the collections and there was no need to lock > otherwise, especially if the query is read-only? > > Thanks, > Thomas > > On Wednesday, April 5, 2017 at 2:30:04 PM UTC+8, Jan wrote: >> >> Hi Thomas, >> >> this should only happen when such queries dynamically access collections, >> so that it is not clear at query start with collections will be accessed. >> This may be the case for graph traversals or for queries that invoke the >> `DOCUMENT()` AQL function using runtime expressions or variables. >> >> Consider the following example: >> >> Query 1 (the read-only query) accesses collection A (which will be >> read-locked when the query starts) >> Query 2 (some other write query) may now start and try to write-lock >> collections B and A. >> >> Query 2 may succeed in getting the lock for B, but not for A (because >> query 1 has got it). >> >> If Query 1 now dynamically needs to access collection B, then none of the >> two queries would make any progress: >> - query 1 would need to wait for the lock on collection B (which is held >> by query 2), >> - query 2 would need to wait for the lock on collection A (which is held >> by query 1) >> >> This is when the deadlock detection starts and will abort one of the >> queries. This can also be a read-only query. >> Deadlocks should not happen if all collections needed by a query can be >> determined at query compile time. Then the locking order should be fully >> deterministic and deadlock-free. >> But when collections are accessed dynamically, there can be no >> deterministic locking order. >> A workaround for avoiding deadlocks is to specify extra collections >> (those that will be accessed dynamically) in a `WITH` clause at the >> beginning of an AQL query, e.g. >> >> WITH extracollection1, extracollection2 >> FOR doc IN collection >> ... >> >> Best regards >> Jan >> >> >> >> Am Mittwoch, 5. April 2017 04:59:53 UTC+2 schrieb Thomas Weiss: >>> >>> Hi there, >>> >>> I've just seen in my logs that requests have failed with the "deadlock >>> detected (while executing)" message, but those requests were all read-only >>> AQL queries. How can such requests be involved in a deadlock? >>> >>> Thanks, >>> Thomas >>> >> -- You received this message because you are subscribed to the Google Groups "ArangoDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
