Repository files navigation

This Laravel package introduces Transaction-aware Event Dispatcher.
It ensures the events dispatched within a database transaction are dispatched only if the outer transaction successfully commits. Otherwise, the events are discarded and never dispatched.

Note:Laravel 8.17 introduced a new methodDB::afterCommit that allows one to achieve the same of this package. Yet, it lacks transaction-aware behavior support for Eloquent events.

• Motivation
• Installation
  • Laravel
  • Lumen
• Usage
• Configuration
• F.A.Q.

Consider the following example of ordering tickets that involves changes to the database.
TheorderTickets dispatches the customOrderCreated event.In turn, its listener sends an email to the user with the order details.

DB::transaction(function() {...$order =$concert->orderTickets($user,3);// internally dispatches 'OrderCreated' event    PaymentService::registerOrder($order);});

In the case of transaction failure, due to an exception in theorderTickets method or even a deadlock, the database changes are completely discarded.

Unfortunately, this is not true for the already dispatchedOrderCreated event.This results in sending the order confirmation email to the user, even after the order failure.

The purpose of this package is thus to hold events dispatched within a database transaction until it successfully commits.In the above example theOrderCreated event would never be dispatched in the case of transaction failure.

• Install this package viacomposer:

composer require fntneves/laravel-transactional-events

• Publish the providedtransactional-events.php configuration file:

php artisan vendor:publish --provider="Neves\Events\EventServiceProvider"

• Install this package viacomposer:

composer require fntneves/laravel-transactional-events

• Manually copy the providedtransactional-events.php configuration file to theconfig folder:

cp vendor/fntneves/laravel-transactional-events/src/config/transactional-events.php config/transactional-events.php

• Register the configuration file and the service provider inbootstrap/app.php:
  

// Ensure the original EventServiceProvider is registered first, otherwise your event listeners are overriden.$app->register(App\Providers\EventServiceProvider::class);$app->configure('transactional-events');$app->register(Neves\Events\EventServiceProvider::class);

The transaction-aware layer is enabled out of the box for the events under theApp\Events namespace.

This package offers three distinct ways to dispatch transaction-aware events:

• Implement theNeves\Events\Contracts\TransactionalEvent contract;
• Use the genericTransactionalClosureEvent event;
• Use theNeves\Events\transactional helper;
• Change theconfiguration file.

The simplest way to mark events as transaction-aware events is implementing theNeves\Events\Contracts\TransactionalEvent contract:

namespaceApp\Events;useIlluminate\Queue\SerializesModels;useIlluminate\Foundation\Events\Dispatchable;...useNeves\Events\Contracts\TransactionalEvent;class TicketsOrderedimplements TransactionalEvent{use Dispatchable, InteractsWithSockets, SerializesModels;...}

And that's it. There are no further changes required.

This package provides a genericTransactionalClosureEvent event for bringing the transaction-aware behavior to custom behavior without requiring specific events.

One relevant use case is to ensure that Jobs are dispatched only after the transaction successfully commits:

DB::transaction(function () {...    Event::dispatch(newTransactionalClosureEvent(function () {// Job will be dispatched only if the transaction commits.        ProcessOrderShippingJob::dispatch($order);    });...});

And that's it. There are no further changes required.

The configuration file includes the following parameters:

Enable or disable the transaction-aware behavior:

'enable' => true

By default, the transaction-aware behavior will be applied to all events under theApp\Events namespace.
Feel free to use patterns and namespaces.

'transactional' => ['App\Events']

Choose the events that should always bypass the transaction-aware layer, i.e., should be handled by the original event dispatcher. By default, all*ed Eloquent events are excluded. The main reason for this default value is to avoid interference with your already existing event listeners for Eloquent events.

'excluded' => [// 'eloquent.*','eloquent.booted','eloquent.retrieved','eloquent.saved','eloquent.updated','eloquent.created','eloquent.deleted','eloquent.restored',],

Yes. As mentioned inUsage, you can use the genericTransactionalClosureEvent(Closure $callable) event to trigger jobs only after the transaction commits.

This package is open-sourced software licensed under theMIT license.