diff --git a/.github/workflows/coding-standards.yml b/.github/workflows/coding-standards.yml index 0ccfa8bc2f..e756cea228 100644 --- a/.github/workflows/coding-standards.yml +++ b/.github/workflows/coding-standards.yml @@ -11,4 +11,4 @@ on: jobs: coding-standards: name: "Coding Standards" - uses: "doctrine/.github/.github/workflows/coding-standards.yml@7.2.1" + uses: "doctrine/.github/.github/workflows/coding-standards.yml@7.2.2" diff --git a/.github/workflows/release-on-milestone-closed.yml b/.github/workflows/release-on-milestone-closed.yml index 45ed91f131..c0bfaa8656 100644 --- a/.github/workflows/release-on-milestone-closed.yml +++ b/.github/workflows/release-on-milestone-closed.yml @@ -8,7 +8,7 @@ on: jobs: release: name: "Git tag, release & create merge-up PR" - uses: "doctrine/.github/.github/workflows/release-on-milestone-closed.yml@7.2.1" + uses: "doctrine/.github/.github/workflows/release-on-milestone-closed.yml@7.2.2" secrets: GIT_AUTHOR_EMAIL: ${{ secrets.GIT_AUTHOR_EMAIL }} GIT_AUTHOR_NAME: ${{ secrets.GIT_AUTHOR_NAME }} diff --git a/.github/workflows/website-schema.yml b/.github/workflows/website-schema.yml index cc8c0c7f29..e51b4a588e 100644 --- a/.github/workflows/website-schema.yml +++ b/.github/workflows/website-schema.yml @@ -18,4 +18,4 @@ on: jobs: json-validate: name: "Validate JSON schema" - uses: "doctrine/.github/.github/workflows/website-schema.yml@7.2.1" + uses: "doctrine/.github/.github/workflows/website-schema.yml@7.2.2" diff --git a/docs/en/reference/transactions-and-concurrency.rst b/docs/en/reference/transactions-and-concurrency.rst index 160ac34d48..97cd2f32df 100644 --- a/docs/en/reference/transactions-and-concurrency.rst +++ b/docs/en/reference/transactions-and-concurrency.rst @@ -377,19 +377,19 @@ You can use pessimistic locks in two different scenarios: .. warning:: - | A few things could go wrong: - | - | If a request fails to complete (e.g. unhandled exception), you may end up with stale locks. - Said locks would need to be manually released or you would need to devise a strategy to automatically do so. - One way to mitigate stale locks after an application error would be to gracefully catch the exception - and ensure that relevant documents are unlocked before the request ends. - | - | `Deadlock `_ situations are also possible. - Suppose process P1 needs resource R1 and has locked resource R2 - and that another process P2 has locked resource R1 but also needs resource R2. - If both processes continue waiting for the respective resources, the application will be stuck. - When loading a document, Doctrine can immediately throw an exception if it is already locked. - A deadlock could be created by endlessly retrying attempts to acquire the lock. - One can avoid a possible deadlock by designating a maximum number of retry attempts - and automatically releasing any active locks with the request ends, - thereby allowing a process to end gracefully while another completes its task. + A few things could go wrong: + + If a request fails to complete (e.g. unhandled exception), you may end up with stale locks. + Said locks would need to be manually released or you would need to devise a strategy to automatically do so. + One way to mitigate stale locks after an application error would be to gracefully catch the exception + and ensure that relevant documents are unlocked before the request ends. + + `Deadlock `_ situations are also possible. + Suppose process P1 needs resource R1 and has locked resource R2 + and that another process P2 has locked resource R1 but also needs resource R2. + If both processes continue waiting for the respective resources, the application will be stuck. + When loading a document, Doctrine can immediately throw an exception if it is already locked. + A deadlock could be created by endlessly retrying attempts to acquire the lock. + One can avoid a possible deadlock by designating a maximum number of retry attempts + and automatically releasing any active locks with the request ends, + thereby allowing a process to end gracefully while another completes its task.