PHPackages                             mehr-it/lara-transaction-waiting-events - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. mehr-it/lara-transaction-waiting-events

ActiveLibrary

mehr-it/lara-transaction-waiting-events
=======================================

Events waiting for database transactions to complete (MySql only)

1.4.0(3y ago)0662[4 PRs](https://github.com/mehr-it/lara-transaction-waiting-events/pulls)MITPHPPHP >=7.1

Since Nov 28Pushed 3y agoCompare

[ Source](https://github.com/mehr-it/lara-transaction-waiting-events)[ Packagist](https://packagist.org/packages/mehr-it/lara-transaction-waiting-events)[ RSS](/packages/mehr-it-lara-transaction-waiting-events/feed)WikiDiscussions master Synced 1mo ago

READMEChangelogDependencies (3)Versions (10)Used By (0)

Laravel events waiting for transactions to complete
===================================================

[](#laravel-events-waiting-for-transactions-to-complete)

This package implements queued events for Laravel which are **guaranteed not be handled before** any pending database transaction has been closed.

Why is it necessary?
--------------------

[](#why-is-it-necessary)

Queued event listeners often rely on data that is written by the event emitter. Even the usage of database transactions is required or at least extremely recommendable, Laravel does not offer a mechanism to block event handling after any pending database transactions are done.

Many other packages dealing with events and transactions, simply collect events in memory until the database transactions have been committed. Then they send them to queue. However if the process runs into an error condition after committing and before having sent all events to the queue, you will lose some events. Imagine a customer order never being processed due to a lost event...

It would be much better to emit the event first and then commit the database transaction after the event has been sent (Note: the event handler must gracefully handle cases where the transaction is rolled back - which usually is simple).

How does it work?
-----------------

[](#how-does-it-work)

Whenever an event is dispatched to a queued listener while a database transaction is open, the event dispatcher will write a lock entry to the database which is released as soon as the transaction is closed. Queued listeners wait for the "transaction lock" to be released before being invoked. That's all we need.

**Important: Event listeners are invoked even after the transaction has been rolled back**! It's up to the listener to deal with cases like this. Since it is always a very good idea that the listener checks any preconditions when invoked (instead of assuming a specific state of the system), their should be no extra work here.

### Implementation details

[](#implementation-details)

This packages extends Laravel's event dispatcher to set "transaction locks" whenever a queued listener (marked with the `WaitsForTransactions` interface) is invoked. It uses [MySQL locking functions](https://dev.mysql.com/doc/refman/5.7/en/locking-functions.html) to set the "transaction locks". Therefore, **this package only works for MySQL connections**. The lock implementation assures that locks are always removed when a transaction ends. No matter if committed, rolled back or the process died unexpectedly.

Before calling the queued listener, any transaction locks are checked for existence. If a transaction lock still exists, event handling job is released to the queue again and is retried later.

Requirements
------------

[](#requirements)

- Laravel >= 5.8
- PHP >= 7.1
- MySQL >= 5.7.5

**This package only works with MySQL database connections!**

Installation
------------

[](#installation)

```
composer require mehr-it/lara-transaction-waiting-events

```

This package uses Laravel's package auto-discovery, so the service provider and aliases will be loaded automatically.

Usage
-----

[](#usage)

There is only one thing to do, to make queued event handlers wait for transactions to be complete. The `WaitsForTransactions` marker interface has to be added to the listener class:

```
class Listener implements ShouldQueue, WaitsForTransactions
{
    public function handle($event) {

    }
}

```

### Specify transaction lock details

[](#specify-transaction-lock-details)

The listener may specify some options for the transaction locks:

#### Custom connection

[](#custom-connection)

By default listeners only wait for transactions using the default DB connection. You may pass in another connection name or specify multiple connections using the `waitForTransactions` property:

```
class Listener implements ShouldQueue, WaitsForTransactions
{
    public $waitForTransactions = ['default-connection', 'secondary-connection'];

    public function handle($event) {

    }
}

```

#### Timeout and retry delay

[](#timeout-and-retry-delay)

By default, the listener waits up to 1s for transactions to complete. If yet not complete, the handler job is released back to queue to be retried in 5s. If you are using long-running transactions, you might want to adapt these values:

```
class Listener implements ShouldQueue, WaitsForTransactions
{
    // the time to wait for transactions to complete
    public $waitForTransactionsTimeout = 7;

    // the retry delay
    public $waitForTransactionsRetryAfter = 30;

    public function handle($event) {

    }
}

```

### Disable transaction waiting events

[](#disable-transaction-waiting-events)

Sometimes - especially when running tests or using the 'sync' queue driver - you might want to disable transaction waiting events and dispatch them even if the transaction has not been committed yet. You can do so, by setting `EVENTS_WAIT_FOR_TRANSACTIONS` to `false` in your .env file:

```
EVENTS_WAIT_FOR_TRANSACTIONS=false

```

###  Health Score

27

—

LowBetter than 49% of packages

Maintenance20

Infrequent updates — may be unmaintained

Popularity13

Limited adoption so far

Community6

Small or concentrated contributor base

Maturity58

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~309 days

Total

5

Last Release

1120d ago

### Community

Maintainers

![](https://avatars.githubusercontent.com/u/44973729?v=4)[mehr.IT GmbH](/maintainers/mehr-it)[@mehr-it](https://github.com/mehr-it)

---

Top Contributors

[![chmgr](https://avatars.githubusercontent.com/u/94837732?v=4)](https://github.com/chmgr "chmgr (1 commits)")

###  Code Quality

TestsPHPUnit

### Embed Badge

![Health badge](/badges/mehr-it-lara-transaction-waiting-events/health.svg)

```
[![Health](https://phpackages.com/badges/mehr-it-lara-transaction-waiting-events/health.svg)](https://phpackages.com/packages/mehr-it-lara-transaction-waiting-events)
```

###  Alternatives

[anourvalar/eloquent-serialize

Laravel Query Builder (Eloquent) serialization

11320.2M21](/packages/anourvalar-eloquent-serialize)[namu/wirechat

A Laravel Livewire messaging app for teams with private chats and group conversations.

54324.5k](/packages/namu-wirechat)[statamic-rad-pack/runway

Eloquently manage your database models in Statamic.

135192.6k5](/packages/statamic-rad-pack-runway)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)