Documentation/rdb exclusive options (#7548)

Documentation/Books/AQL/Operations/Insert.md

@@ -100,13 +100,12 @@ FOR i IN 1..1000
   } INTO users OPTIONS { overwrite: true }
 ```
 
-
 In contrast to the MMFiles engine, the RocksDB engine does not require collection-level
 locks. Different write operations on the same collection do not block each other, as
 long as there are no _write-write conficts_ on the same documents. From an application
 development perspective it can be desired to have exclusive write access on collections,
-to simplify the development. Note that writes do not block reads in rocksdb.
-Exclusive access can also speed up modification queries, because we avoid conflict checks.<br/>
+to simplify the development. Note that writes do not block reads in RocksDB.
+Exclusive access can also speed up modification queries, because we avoid conflict checks.
 
 Use the *exclusive* option to achieve this effect on a per query basis:
 

Documentation/Books/AQL/Operations/Remove.md

@@ -122,8 +122,8 @@ In contrast to the MMFiles engine, the RocksDB engine does not require collectio
 locks. Different write operations on the same collection do not block each other, as
 long as there are no _write-write conficts_ on the same documents. From an application
 development perspective it can be desired to have exclusive write access on collections,
-to simplify the development. Note that writes do not block reads in rocksdb.
-Exclusive access can also speed up modification queries, because we avoid conflict checks.<br/>
+to simplify the development. Note that writes do not block reads in RocksDB.
+Exclusive access can also speed up modification queries, because we avoid conflict checks.
 
 Use the *exclusive* option to achieve this  effect on a per query basis:
 

Documentation/Books/AQL/Operations/Replace.md

@@ -115,8 +115,8 @@ In contrast to the MMFiles engine, the RocksDB engine does not require collectio
 locks. Different write operations on the same collection do not block each other, as
 long as there are no _write-write conficts_ on the same documents. From an application
 development perspective it can be desired to have exclusive write access on collections,
-to simplify the development. Note that writes do not block reads in rocksdb.
-Exclusive access can also speed up modification queries, because we avoid conflict checks.<br/>
+to simplify the development. Note that writes do not block reads in RocksDB.
+Exclusive access can also speed up modification queries, because we avoid conflict checks.
 
 Use the *exclusive* option to achieve this effect on a per query basis:
 

Documentation/Books/AQL/Operations/Update.md

@@ -230,13 +230,12 @@ FOR i IN 1..1000
   OPTIONS { ignoreRevs: false }
 ```
 
-
 In contrast to the MMFiles engine, the RocksDB engine does not require collection-level
 locks. Different write operations on the same collection do not block each other, as
 long as there are no _write-write conficts_ on the same documents. From an application
 development perspective it can be desired to have exclusive write access on collections,
-to simplify the development. Note that writes do not block reads in rocksdb.
-Exclusive access can also speed up modification queries, because we avoid conflict checks.<br/>
+to simplify the development. Note that writes do not block reads in RocksDB.
+Exclusive access can also speed up modification queries, because we avoid conflict checks.
 
 Use the *exclusive* option to achieve this effect on a per query basis:
 

Documentation/Books/AQL/Operations/Upsert.md

@@ -99,21 +99,20 @@ the searchExpression. Even worse, if you use an outdated `_rev` in the searchExp
 UPSERT will trigger the INSERT path instead of the UPDATE path, because it has not found a document
 exactly matching the searchExpression.
 
-
 In contrast to the MMFiles engine, the RocksDB engine does not require collection-level
 locks. Different write operations on the same collection do not block each other, as
 long as there are no _write-write conficts_ on the same documents. From an application
 development perspective it can be desired to have exclusive write access on collections,
-to simplify the development. Note that writes do not block reads in rocksdb.
-Exclusive access can also speed up modification queries, because we avoid conflict checks.<br/>
+to simplify the development. Note that writes do not block reads in RocksDB.
+Exclusive access can also speed up modification queries, because we avoid conflict checks.
 
 Use the *exclusive* option to achieve this effect on a per query basis:
 
 ```js
 FOR i IN 1..1000
-  UPSERT { _key: CONCAT('test', i)}
-  INSERT {foobar: false}
-  UPDATE {foobar: true }
+  UPSERT { _key: CONCAT('test', i) }
+  INSERT { foobar: false }
+  UPDATE { foobar: true }
   IN users OPTIONS { exclusive: true }
 ```
 

Documentation/Books/Manual/DataModeling/OperationalFactors.md

@@ -262,18 +262,18 @@ the `intermediateCommitCount` option in the API to subdivide the AQL transaction
 ### Read / Write Load Balance
 
 Depending on whether your data model has a higher read- or higher write-rate you may want
-to adjust some of the rocksdb specific options. Some of the most critical options to
+to adjust some of the RocksDB specific options. Some of the most critical options to
 adjust the performance and memory usage are listed below:
 
 `--rocksdb.block-cache-size`
 
-This is the size of the block cache in bytes. This cache is used for read operations, 
-increasing the size of this may improve the performance of read heavy workloads.
+This is the size of the block cache in bytes. This cache is used for read operations.
+Increasing the size of this may improve the performance of read heavy workloads.
 You may wish to adjust this parameter to control memory usage.
 
 `--rocksdb.write-buffer-size`
 
-Amount of data to build up in memory before converting to a file on disk. 
+Amount of data to build up in memory before converting to a file on disk.
 Larger values increase performance, especially during bulk loads.
 
 `--rocksdb.max-write-buffer-number`