v4.4.1

Full Changelog: v4.4.0...v4.4.1

v4.4.0

What's Changed

• docs: ✏️ Nested Transactions by @mpyw in #9
• fix: ci failure on testbench 9.x-dev by @KentarouTakeda in #11
• Bump version and Fixes wrong documentation by @mpyw in #13

New Contributors

• @KentarouTakeda made their first contribution in #11

Full Changelog: v4.3.0...v4.4.0

v4.3.0

What's Changed

• feat: 🎸 Support float precision for Postgres by @mpyw in #8

Full Changelog: v4.2.3...v4.3.0

v4.2.3

What's Changed

• feat: 🎸 Utilize lock_timeout to eliminate loops by @mpyw in #7

Full Changelog: v4.2.2...v4.2.3

v4.2.2

chore: 🤖 Drop support for stale versions

v4.2.1

v4.2.1: Fix bugs of finite timeout emulation for Postgres by mpyw · Pull Request #5 · mpyw/laravel-database-advisory-lock

Fix bugs of finite timeout emulation for Postgres (#4)

A bug that transactions unexpectedly aborted was solved by creating a temporary function in pg_temp instead of using DO + RAISE.

v4.2.0

v4.2.0 with New Features by mpyw · Pull Request #4 · mpyw/laravel-database-advisory-lock

Finite timeout emulation for Postgres

Postgres, like MySQL, can now wait a specified finite time to acquire a lock.

v4.1.0

v4.1.0 with New Features by mpyw · Pull Request #3 · mpyw/laravel-database-advisory-lock

Change MySQL function LENGTH() into CHAR_LENGTH()

Up to previous versions, MySQL lock keys were calculated by LENGTH() as a number of bytes in length. Actually, they should have been computed as multibyte strings by CHAR_LENGTH().

Allow -1 (infinite wait) for Postgres timeout

Until previous versions, Postgres could not handle negative timeout seconds. With this change, it is now possible to wait infinitely. Note that it is still not possible to wait with a certain time limit.

Follow Laravel 10 breaking changes

Starting with Laravel 10, the following pull request changes the constructor signature of LockFailedException.

• laravel/framework#43190

v4.0.0

v4.0.0 with Major Changes by mpyw · Pull Request #2 · mpyw/laravel-database-advisory-lock

What's the matter?

Up to version 3.x, the Postgres driver had a fatal problem. When a session-level lock was acquired in a transaction, it was not always possible to release the lock during the finally blocks; once Postgres encountered an error in a transaction, it would kill all continuing operations with an error.

Two approaches were adopted to solve this problem:

Monitoring for commit/rollback events (including rollbacks to savepoints)

Even if the lock release process fails, it can be recovered by performing commit/rollback operations. When the event is detected, we will retry the lock release process.

Issue savepoints on withLocking() calls

If a transaction has already been opened, a savepoint is created immediately after lock acquisition so that the lock can be released on the fly after recovering from an error that occurred within the callback function.

Changes

• AdvisoryLockServiceProvider has been added; which is automatically discovered.
• withLocking() takes ConnectionInterface as a first argument.