Fix heading capitalization

Author: emirmx

content/en/docs/refguide/runtime/optimistic-locking.md

@@ -14,49 +14,49 @@ Optimistic locking is a strategy used in concurrent systems to prevent **lost up
 
 If a conflict is detected—meaning someone else has modified the data since you last read it—your update is rejected, and you typically have to re-read the data and try again.
 
-## Project with Optimistic locking disabled
+## Project With Optimistic Locking Disabled
 
 When two modifications are saved, they are applied in the order of processing. Only changed attributes are written to the database. This means that if two objects with disjoint sets of changed attributes are committed, the changes are not overwritten.
 
 For example, if one user commits changes for `AttributeA` and `AttributeB` and another user commits changes for `AttributeB` and `AttributeC` for the same object, then both `AttributeA` and `AttributeC` are committed according to both users' changes. `AttributeB` is committed based on whichever change was committed last.
 
-## Project with Optimistic locking enabled
+## Project With Optimistic Locking Enabled
 
 The Mendix runtime implements optimistic locking by introducing a new attribute named `MxObjectVersion` with type `Long` to all entities tracking their version. The `MxObjectVersion` attribute is not write-protected. However, setting this value will **not** result in it being saved to the database. Its current value will be compared with the value for the same record in the database.
 
-### How to enable and use optimistic locking
+### How to Enable and Use Optimistic Locking
 
 Optimistic locking can be enabled per Mendix application using the `Runtime` tab in the App settings dialog:
 
 {{< figure src="/attachments/refguide/runtime/optimistic-locking/runtime-settings-dialog.png" >}}
 
 After optimistic locking is enabled, whenever a commit is executed, the Mendix runtime will automatically ensure that the object that is committed was not already changed by another party after the committer read the object.
 
-### New projects and migration
+### New Projects and Migration
 
 In case an existing app already had the `MxObjectVersion` attribute, when optimistic locking is enabled a duplicate attribute will be reported in the Modeler. This must be fixed by renaming the existing attribute to another name. The system attribute cannot be renamed.
 
 ### Behavior
 
 Here we describe how various runtime actions are influenced by optimistic locking:
 
-#### Create object
+#### Create Object
 
 Initialize the `MxObjectVersion` attribute to `0`.
 
-#### Commit object
+#### Commit Object
 
 When the `MxObjectVersion` attribute in the object being committed is different from the value in the database, or the object was deleted from the database, throw a `ConcurrentModificationRuntimeException`. Otherwise, proceed with the commit while incrementing `MxObjectVersion` by one.
 
-#### Delete object
+#### Delete Object
 
 When the `MxObjectVersion` attribute in the object being deleted is different from the value in the database, throw a `ConcurrentModificationRuntimeException`. Otherwise, proceed with the delete. If the object was already deleted, no error occurs, as is the case without optimistic locking.
 
-## Performance impact
+## Performance Impact
 
 Because of the version check performed during commit and delete, optimistic locking incurs some minor performance impact.
 
-## Handling optimistic locking errors in Microflows
+## Handling Optimistic Locking Errors in Microflows
 
 When an optimistic locking error occurs, the runtime log contains an entry similar to the following:
 
@@ -83,26 +83,26 @@ An example can be seen below. The change action has error handling `Custom witho
 
 Check the [documentation](https://docs.mendix.com/refguide/error-handling-in-microflows/) about error handling to find more information about differences between `Custom with Rollback` and `Custom without Rollback`.
 
-## Handling optimistic locking errors in Java actions
+## Handling Optimistic Locking Errors in Java Actions
 
-In Java actions an optimistic locking error can be handled by similar steps described in [Handling optimistic locking errors in Microflows]. However, the `com.mendix.systemwideinterfaces.connectionbus.data.ConcurrentModificationRuntimeException` exception will not be the top level exception thrown by the Mendix runtime. It will be wrapped in another exception, so the `cause` chain of caught exceptions should be inspected.
+In Java actions an optimistic locking error can be handled by similar steps described in [Handling Optimistic Locking Errors in Microflows]. However, the `com.mendix.systemwideinterfaces.connectionbus.data.ConcurrentModificationRuntimeException` exception will not be the top level exception thrown by the Mendix runtime. It will be wrapped in another exception, so the `cause` chain of caught exceptions should be inspected.
 
-## Handling optimistic locking errors in the client
+## Handling Optimistic Locking Errors in the Client
 
 If the optimistic locking error is propagated to the client, then an error dialog is shown as follows:
 
 {{< figure src="/attachments/refguide/runtime/optimistic-locking/optimistic-locking-error-dialog.png" >}}
 
 To handle the optimistic locking error one of the following strategies can be used:
 
-### Single `Save` button
+### Single `Save` Button
 
 In this case user can refresh the whole page losing all changes.
 
-### `Save` button with a separate `Refresh` button
+### `Save` Button With a Separate `Refresh` Button
 
 A separate `Refresh` button that retrieves the latest object state from the database and applies the original changes onto the retrieved object. After clicking the `Refresh` button, the user can inspect the latest state and can click the `Save` button again.
 
-### Custom `Save` button
+### Custom `Save` Button
 
-A custom `Save` button that retries saving object using similar steps described in [Handling optimistic locking errors in Microflows], to retry until successful.
+A custom `Save` button that retries saving object using similar steps described in [Handling Optimistic Locking Errors in Microflows], to retry until successful.