Fixes

Author: javiereguiluz

components/lock.rst

@@ -273,21 +273,21 @@ Remote stores (:ref:`MemcachedStore <lock-store-memcached>` and
 :ref:`RedisStore <lock-store-redis>`) use an unique token to recognize the true
 owner of the lock. This token is stored in the
 :class:`Symfony\\Component\\Lock\\Key` object and is used internally by the
-``Lock``, therefore this Key must not be shared between processes (Session,
-Caching, fork, ...).
+``Lock``, therefore this key must not be shared between processes (session,
+caching, fork, ...).
 
 .. caution::
 
-    Do not share a Key between processes.
+    Do not share a key between processes.
 
-Every concurrent process must store the ``Lock`` in the same Server otherwise two
-distinguished machines may allow two distinguished process to acquire the same ``Lock``.
+Every concurrent process must store the ``Lock`` in the same server. Otherwise two
+different machines may allow two different processes to acquire the same ``Lock``.
 
 .. caution::
 
-    To guarantee that the same Server will always be sure, do not use Memcached
+    To guarantee that the same server will always be safe, do not use Memcached
     behind a LoadBalancer, a cluster or round-robin DNS. Even if the main server
-    is Down, the calls must not be forwarded to a backup or failover server.
+    is down, the calls must not be forwarded to a backup or failover server.
 
 Expiring Stores
 ~~~~~~~~~~~~~~~
@@ -298,11 +298,11 @@ only for the defined duration of time. If the task takes longer to be
 accomplished, then the lock can be released by the store and acquired by
 someone else.
 
-The ``Lock`` provide several methods to check it health. The ``isExpired``
-method provide an quick way to check whether or not it lifetime is over.
-While the ``getRemainingLifetime`` method returns it time to live in seconds.
+The ``Lock`` provides several methods to check its health. The ``isExpired()``
+method checks whether or not it lifetime is over and the ``getRemainingLifetime()``
+method returns its time to live in seconds.
 
-With the above methods, a more robust code would be::
+Using the above methods, a more robust code would be::
 
     // ...
     $lock = $factory->createLock('invoice-publication', 30);
@@ -311,7 +311,7 @@ With the above methods, a more robust code would be::
     while (!$finished) {
         if ($lock->getRemainingLifetime() <= 5) {
             if ($lock->isExpired()) {
-                // reliability was lost, perform a rollback or send a notification
+                // lock was lost, perform a rollback or send a notification
                 throw new \RuntimeException('Lock lost during the overall process');
             }
 
@@ -323,49 +323,48 @@ With the above methods, a more robust code would be::
 
 .. caution::
 
-    Choose wisely the lifetime of the ``Lock``. And check if it remaining
+    Choose wisely the lifetime of the ``Lock`` and check whether its remaining
     time to leave is enough to perform the task.
 
 .. caution::
 
-    Storing a ``Lock`` could take time. Even if, most of the time, it take
-    few milliseconds, Network, may have trouble and the duration to perform
-    this simple task could be up to few seconds. Take it into accound when
-    choosing the right TTL.
+    Storing a ``Lock`` usually takes a few milliseconds, but network conditions
+    may increase that time a lot (up to a few seconds). Take that into account
+    when choosing the right TTL.
 
-By design, Lock are stored in Server with a defined Lifetime. If the date or
-time of the machine changes, a Lock could be released sooner than expected.
+By design, locks are stored in servers with a defined lifetime. If the date or
+time of the machine changes, a lock could be released sooner than expected.
 
 .. caution::
 
-    To guarantee that date wouldn't change, the NTP service should be disabled
-    and the date should be updated when while the service is stopped.
+    To guarantee that date won't change, the NTP service should be disabled
+    and the date should be updated when the service is stopped.
 
 FlockStore
 ~~~~~~~~~~
 
 By using the file system, this ``Store`` is reliable as long as concurrent
 processes use the same physical directory to stores locks.
 
-Processes must run on the same Machine, Virtual Machine or Container.
+Processes must run on the same machine, virtual machine or container.
 Be careful when updating a Kubernetes or Swarm service because for a short
-period of time, there can be 2 running containers in parallel.
+period of time, there can be two running containers in parallel.
 
-The absolute path to the directory must remain the same. Be careful to
-symlinks on the path that could change at anytime: Capistrano and blue/green
-deployment often use that trick. Be careful when the path to that directory
-change between 2 deployments.
+The absolute path to the directory must remain the same. Be careful of symlinks
+that could change at anytime: Capistrano and blue/green deployment often use
+that trick. Be careful when the path to that directory changes between two
+deployments.
 
 Some file systems (such as some types of NFS) do not support locking.
 
 .. caution::
 
-    All concurrent processes MUST use the same physical file system by running
+    All concurrent processes must use the same physical file system by running
     on the same machine and using the same absolute path to locks directory.
 
     By definition, usage of ``FlockStore`` in an HTTP context is incompatible
-    with multiple front server, unless to be sure that the same resource will
-    alway be locked on the same machine or to use a well configured shared file
+    with multiple front servers, unless to ensure that the same resource will
+    always be locked on the same machine or to use a well configured shared file
     system.
 
 Files on file system can be removed during a maintenance operation. For instance
@@ -375,26 +374,26 @@ it is in case of ``Lock`` reused between requests.
 
 .. caution::
 
-    Do not store locks on a volatil file system if they have to be reused during
+    Do not store locks on a volatile file system if they have to be reused in
     several requests.
 
 MemcachedStore
 ~~~~~~~~~~~~~~
 
-The way Memcached works is to store items in Memory, that's means that by using
+The way Memcached works is to store items in memory. That means that by using
 the :ref:`MemcachedStore <lock-store-memcached>` the locks are not persisted
 and may disappear by mistake at anytime.
 
-If the Memcached service or the machine hosting it restarts, every locks would
-be lost without notify running processes.
+If the Memcached service or the machine hosting it restarts, every lock would
+be lost without notifying the running processes.
 
 .. caution::
 
-    To avoid that someone else acquires a lock after a restart, we recommend
-    to delayed service start and wait at least as long as the longest lock TTL.
+    To avoid that someone else acquires a lock after a restart, it's recommended
+    to delay service start and wait at least as long as the longest lock TTL.
 
-By default Memcached use a LRU mechanism to remove old entries when the service
-need space to add new items.
+By default Memcached uses a LRU mechanism to remove old entries when the service
+needs space to add new items.
 
 .. caution::
 
@@ -403,73 +402,73 @@ need space to add new items.
     Memcached service away from Cache.
 
 When the Memcached service is shared and used for multiple usage, Locks could be
-removed by mistake. For instance some implementation of the PSR-6 ``clear``
-method use the Memcached's ``flush`` method which purge and remove everything.
+removed by mistake. For instance some implementation of the PSR-6 ``clear()``
+method uses the Memcached's ``flush()`` method which purges and removes everything.
 
 .. caution::
 
-    The method ``flush`` MUST not be called, or Locks should be stored in a
+    The method ``flush()`` must not be called, or locks should be stored in a
     dedicated Memcached service away from Cache.
 
 RedisStore
 ~~~~~~~~~~
 
-The way Redis works is to store items in Memory, that's means that by using
+The way Redis works is to store items in memory. That means that by using
 the :ref:`RedisStore <lock-store-redis>` the locks are not persisted
 and may disappear by mistake at anytime.
 
 If the Redis service or the machine hosting it restarts, every locks would
-be lost without notify running processes.
+be lost without notifying the running processes.
 
 .. caution::
 
-    To avoid that someone else acquires a lock after a restart, we recommend
-    to delayed service start and wait at least as long as the longest lock TTL.
+    To avoid that someone else acquires a lock after a restart, it's recommended
+    to delay service start and wait at least as long as the longest lock TTL.
 
 .. tips::
 
     Redis can be configured to persist items on disk, but this option would
     slow down writes on the service. This could go against other uses of the
     server.
 
-When the Redis service is shared and used for multiple usage, Locks could be
+When the Redis service is shared and used for multiple usages, locks could be
 removed by mistake.
 
 .. caution::
 
-    The command ``FLUSHDB`` MUST not be called, or Locks should be stored in a
+    The command ``FLUSHDB`` must not be called, or locks should be stored in a
     dedicated Redis service away from Cache.
 
 CombinedStore
 ~~~~~~~~~~~~~
 
-Combined stores allows to store locks across several backend. It's a common
+Combined stores allow to store locks across several backends. It's a common
 mistake to think that the lock mechanism will be more reliable. This is wrong
-The ``CombinedStore`` will be, at best, as reliable than the less reliable of
+The ``CombinedStore`` will be, at best, as reliable as the least reliable of
 all managed stores. As soon as one managed store returns erroneous information,
-the ``CombinedStore`` would be not reliable.
+the ``CombinedStore`` won't be reliable.
 
 .. caution::
 
-    All concurrent processes MUST use the same configuration. with the same
+    All concurrent processes must use the same configuration, with the same
     amount of managed stored and the same endpoint.
 
 .. tips::
 
-    Instead of using Cluster of Redis or memcached servers, we recommend to use
-    a ``CombinedStore`` with & single server per managed store.
+    Instead of using a cluster of Redis or Memcached servers, it's better to use
+    a ``CombinedStore`` with a single server per managed store.
 
 SemaphoreStore
 ~~~~~~~~~~~~~~
 
-Semaphore are handled by the Kernel level, to be reliable, processes must run
-on the same Machine, Virtual Machine or Container.
-Be careful when updating a Kubernetes or Swarm service because for a short
-period of time, there can be 2 running containers in parallel.
+Semaphores are handled by the Kernel level. In order to be reliable, processes
+must run on the same machine, virtual machine or container. Be careful when
+updating a Kubernetes or Swarm service because for a short period of time, there
+can be two running containers in parallel.
 
 .. caution::
 
-    All concurrent processes MUST use the same machine. Before starting a
+    All concurrent processes must use the same machine. Before starting a
     concurrent process on a new machine, check that other process are stopped
     on the old one.
 
@@ -478,8 +477,8 @@ Overall
 
 Changing the configuration of stores should be done very carefully. For
 instance, during the deployment of a new version. Processes with new
-configuration MUST NOT be started while Old processes with old configuration
-are still running
+configuration must not be started while old processes with old configuration
+are still running.
 
 .. _`locks`: https://en.wikipedia.org/wiki/Lock_(computer_science)
 .. _Packagist: https://packagist.org/packages/symfony/lock