Skip to content

Commit 2680203

Browse files
authored
Merge pull request #2747 from doctrine/2.10.x
Merge 2.10.x into 2.11.x
2 parents 8c88123 + 8fdc94f commit 2680203

File tree

1 file changed

+16
-16
lines changed

1 file changed

+16
-16
lines changed

docs/en/reference/transactions-and-concurrency.rst

+16-16
Original file line numberDiff line numberDiff line change
@@ -377,19 +377,19 @@ You can use pessimistic locks in two different scenarios:
377377

378378
.. warning::
379379

380-
| A few things could go wrong:
381-
|
382-
| If a request fails to complete (e.g. unhandled exception), you may end up with stale locks.
383-
Said locks would need to be manually released or you would need to devise a strategy to automatically do so.
384-
One way to mitigate stale locks after an application error would be to gracefully catch the exception
385-
and ensure that relevant documents are unlocked before the request ends.
386-
|
387-
| `Deadlock <https://en.wikipedia.org/wiki/Deadlock>`_ situations are also possible.
388-
Suppose process P1 needs resource R1 and has locked resource R2
389-
and that another process P2 has locked resource R1 but also needs resource R2.
390-
If both processes continue waiting for the respective resources, the application will be stuck.
391-
When loading a document, Doctrine can immediately throw an exception if it is already locked.
392-
A deadlock could be created by endlessly retrying attempts to acquire the lock.
393-
One can avoid a possible deadlock by designating a maximum number of retry attempts
394-
and automatically releasing any active locks with the request ends,
395-
thereby allowing a process to end gracefully while another completes its task.
380+
A few things could go wrong:
381+
382+
If a request fails to complete (e.g. unhandled exception), you may end up with stale locks.
383+
Said locks would need to be manually released or you would need to devise a strategy to automatically do so.
384+
One way to mitigate stale locks after an application error would be to gracefully catch the exception
385+
and ensure that relevant documents are unlocked before the request ends.
386+
387+
`Deadlock <https://en.wikipedia.org/wiki/Deadlock>`_ situations are also possible.
388+
Suppose process P1 needs resource R1 and has locked resource R2
389+
and that another process P2 has locked resource R1 but also needs resource R2.
390+
If both processes continue waiting for the respective resources, the application will be stuck.
391+
When loading a document, Doctrine can immediately throw an exception if it is already locked.
392+
A deadlock could be created by endlessly retrying attempts to acquire the lock.
393+
One can avoid a possible deadlock by designating a maximum number of retry attempts
394+
and automatically releasing any active locks with the request ends,
395+
thereby allowing a process to end gracefully while another completes its task.

0 commit comments

Comments
 (0)