Added new sections to Clustered-Environment.md document

docs/en/Background-Jobs.md

@@ -189,12 +189,18 @@ public class MyModule : AbpModule
 
 ### Data Store
 
-The default background job manager needs a data store to save and read jobs. It defines `IBackgroundJobStore` as an abstraction. So, you can replace the implementation if you want.
+The default background job manager needs a data store to save and read jobs. It defines `IBackgroundJobStore` as an abstraction to store the jobs.
 
-Background Jobs module implements `IBackgroundJobStore` using various data access providers. See its own [documentation](Modules/Background-Jobs.md).
+Background Jobs module implements `IBackgroundJobStore` using various data access providers. See its own [documentation](Modules/Background-Jobs.md). If you don't want to use this module, you should implement the `IBackgroundJobStore` interface yourself.
 
 > Background Jobs module is already installed to the startup templates by default and it works based on your ORM/data access choice.
 
+### Clustered Deployment
+
+The default background job manager is compatible with [clustered environments](Deployment/Clustered-Environment.md) (where multiple instances of your application run concurrently). It uses a [distributed lock](Distributed-Locking.md) to ensure that the jobs are executed only in a single application instance in a time.
+
+However, the distributed lock system works in-process by default. That means it is not distributed actually, unless you configure a distributed lock provider. So, please follow the [distributed lock](Distributed-Locking.md) document to configure a provider for your application, if it is not already configured.
+
 ## Integrations
 
 Background job system is extensible and you can change the default background job manager with your own implementation or on of the pre-built integrations.

docs/en/Deployment/Clustered-Environment.md

@@ -65,7 +65,11 @@ Check the [BLOB Storing](../Blob-Storing.md) document to see all available BLOG
 
 ## Configuring Background Jobs
 
-TODO
+ABP's [background job system](../Background-Jobs.md) is used to queue tasks to be executed in background. Background job queue is persistent and a queued task is guaranteed to be executed (it is re-tried if it fails).
+
+ABP's default background job manager is compatible with clustered environments. It uses a [distributed lock](../Distributed-Locking.md) to ensure that the jobs are executed only in a single application instance in a time. See the *Configuring a Distributed Lock Provider* section below to learn how to configure a distributed lock provider for your application, so the default background job manager properly works in a clustered environment.
+
+> If you are using an external background job integration (e.g. [Hangfire](../Background-Workers-Hangfire.md) or [Quartz](../Background-Workers-Quartz.md)) instead of the default background job manager, then please refer your provider's documentation to learn how it should be configured for a clustered environment.
 
 ## Implementing Background Workers
 
@@ -73,4 +77,6 @@ TODO
 
 ## Configuring a Distributed Lock Provider
 
-TODO
+ABP provides a distributed locking abstraction with an implementation made with the [DistributedLock](https://github.com/madelson/DistributedLock) library. A distributed lock is used to control concurrent access to a shared resource by multiple applications to prevent corruption of the resource because of concurrent writes. ABP Framework and some pre-built [application modules](../Modules/Index.md) are using the distributed locking for several reasons.
+
+However, the distributed lock system works in-process by default. That means it is not distributed actually, unless you configure a distributed lock provider. So, please follow the [distributed lock](../Distributed-Locking.md) document to configure a provider for your application, if it is not already configured.

docs/en/Distributed-Locking.md

@@ -1,7 +1,5 @@
 # Distributed Locking
-Distributed locking is a technique to manage many applications that try to access the same resource.
-The main purpose is to allow only one of many applications to access the same resource at the same time.
-Otherwise, accessing the same object from various applications may corrupt the value of resources. 
+Distributed locking is a technique to manage many applications that try to access the same resource. The main purpose is to allow only one of many applications to access the same resource at the same time. Otherwise, accessing the same object from various applications may corrupt the value of resources. 
 
 > ABP's current distributed locking implementation is based on the [DistributedLock](https://github.com/madelson/DistributedLock) library.