PHPackages mehr-it/lara-transactions - 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. [Database & ORM](/categories/database) 4. / 5. mehr-it/lara-transactions ActiveLibrary[Database & ORM](/categories/database) mehr-it/lara-transactions ========================= Handles multiple simultaneous transactions and offers a general transaction interface for laravel 1.2.0(4y ago)05.8k1MITPHPPHP >=7.1CI failing Since Dec 4Pushed 4y agoCompare [ Source](https://github.com/mehr-it/lara-transactions)[ Packagist](https://packagist.org/packages/mehr-it/lara-transactions)[ RSS](/packages/mehr-it-lara-transactions/feed)WikiDiscussions master Synced 2d ago READMEChangelogDependencies (4)Versions (9)Used By (1) Transactions for Laravel ======================== [](#transactions-for-laravel) [![Latest Version on Packagist](https://camo.githubusercontent.com/cd444e98eb7d0a9ff4870d3b5abb89c3754053ff23d0ed49f4f55aa33c825640/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f762f6d6568722d69742f6c6172612d7472616e73616374696f6e732e7376673f7374796c653d666c61742d737175617265)](https://packagist.org/packages/mehr-it/lara-transactions)[![Build Status](https://camo.githubusercontent.com/a2bb4b4ea8d98576766c202e3db7b946abd0672c7dc33dc205bd125b8b7d1c4a/68747470733a2f2f7472617669732d63692e6f72672f6d6568722d69742f6c6172612d7472616e73616374696f6e732e7376673f6272616e63683d6d6173746572)](https://travis-ci.org/mehr-it/lara-transactions) Handles multiple simultaneous transactions and offers a general transaction interface for laravel. Usually transactions are used when working with databases to ensure consistency. But this package manages any kind of transactions (not only database) as long as the `Transaction`interface is implemented. Installation ------------ [](#installation) ``` composer require mehr-it/lara-transactions ``` This package uses Laravel's package auto-discovery, so the service provider and aliases will be loaded automatically. Managing transactions --------------------- [](#managing-transactions) The `Transaction` facade offers three basic method for transactions: ``` Transaction::begin( /* transactional entities */); Transaction::commit(); Transaction::rollback(); ``` These methods behave like the corresponding database operations. You may also use the `run()`-method which executes a callback wrapped in a transaction: ``` Transaction::run( /* transactional entities */ , function() { // put your code here }); ``` This first starts the transaction. Then the callback is executed and after that the transaction is committed. If an Exception is thrown during callback execution, the transaction is rolled back and the exception is thrown. ### Starting transactions [](#starting-transactions) Whenever you want to start a transaction, you first must list the entities which a transaction should be created for. We call these "transactional entities". In the sense of database transactions the transactional entities would be the database connections. You may pass in the connection instance or the connection name: ``` Transaction::begin(DB::connection()); Transaction::begin('myConnection'); Transaction::begin(['myConnection', 'anotherConnection']); Transaction::run('myConnection' , function() { /* ... */ }); ``` As the example shows, it is possible to pass in multiple "transactional entities" to a single `begin()`or `run()` call. For more information see "**Multi transaction handling**" below. However you may also pass a model. The model's underlying database connection is automatically detected and a transaction is started for it: ``` Transaction::begin(MyModel::class); Transaction::begin([$user, $profile]); Transaction::run(MyModel::class , function() { /* ... */ }); ``` If multiple models using the same database connection are passed, only one transaction is started. #### Transactors [](#transactors) Sometimes entities do not implement their transactions on their own. Models are a good example: Their transactions are implemented by the underlying database connections. But it might be more handy to pass in the models directly instead of passing the used database connection. This is where "transactors" come in: A transactor creates the necessary transactions for a given entity and adds them to the pool of manages transactions. For database connections and models, the corresponding transactors are available by default. However you are free to implement your own. Simply implement the `Transactor` interface and register your transactor: ``` Transaction::registerTransactor(EntityClass::class, TransactorClass::class); ``` ### Multi transaction handling [](#multi-transaction-handling) The `Transaction` facade allows to pass in multiple "transactional entities" for which multiple transactions may be created and managed at the same time. The problem with multiple transactions at different connections is, that it can not be assured that all of them commit or fail: They have to be committed one after another. If one commit succeeds and subsequent one fails, inconsistencies may happen. You should avoid multiple transactions wherever possible. But real world examples show, that it is not avoidable in some scenarios. Think of applications requiring multiple databases or using different storage systems. This problem can not be solved, but we could try to minimize the risk. And of course we should report whenever inconsistent commits happen. Our best effort to minimize the risk of inconsistent commits, is to check each transaction to be "alive" right before the first transaction is committed. Only if no transaction seams to be broken, we start committing them one after another. As the time gap between the first transaction being tested and the last one being committed is very low, the risk of a transaction breaking in between is as low as possible. Of course this implies commit operations to be fast and robust (fail rarely). For database transactions the "alive" testing is done by executing a simple "SELECT 1", to see if the server session is still intact. ### Nesting transactions [](#nesting-transactions) You may start new transactions while other transactions are open. Following snippet demonstrates this: ``` Transaction::run([EntityA::class, EntityB::class] , function() { // CodeBlock1 Transaction::run(EntityC::class , function() { // CodeBlock2 }); // CodeBlock3 }); ``` This example works as expected: Between CodeBlock1 and CodeBlock3 another transaction is established. It is started after CodeBlock1 and committed before CodeBlock3 is reached. As long as all entities use the same underlying transaction implementation which supports nesting, there is nothing to worry about. This is true for most database connections. But you have to be careful if EntityC uses a transaction which is independent from the outer entities' transaction(s) (different transaction implementation or other database connection): Failures in the outer transaction would not cause the inner transaction to be rolled back. That's because it's underlying transaction is not nested within the outer underlying transactions. ### Health Score 28 — LowBetter than 54% of packages Maintenance20 Infrequent updates — may be unmaintained Popularity17 Limited adoption so far Community5 Small or concentrated contributor base Maturity58 Maturing project, gaining track record 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 ~95 days Recently: every ~134 days Total 8 Last Release 1681d ago PHP version history (2 changes)1.0.3PHP ^7.1 1.1.0PHP >=7.1 ### Community Maintainers ![](https://avatars.githubusercontent.com/u/44973729?v=4)[mehr.IT GmbH](/maintainers/mehr-it)[@mehr-it](https://github.com/mehr-it) ### Code Quality TestsPHPUnit ### Embed Badge ![Health badge](/badges/mehr-it-lara-transactions/health.svg) ``` [![Health](https://phpackages.com/badges/mehr-it-lara-transactions/health.svg)](https://phpackages.com/packages/mehr-it-lara-transactions) ``` ### Alternatives [anourvalar/eloquent-serialize Laravel Query Builder (Eloquent) serialization 11320.2M21](/packages/anourvalar-eloquent-serialize)[overtrue/laravel-versionable Make Laravel model versionable. 585308.0k5](/packages/overtrue-laravel-versionable)[abbasudo/laravel-purity elegant way to add filter and sort in laravel 514330.5k1](/packages/abbasudo-laravel-purity)[statamic-rad-pack/runway Eloquently manage your database models in Statamic. 135192.6k5](/packages/statamic-rad-pack-runway)[dragon-code/laravel-deploy-operations Performing any actions during the deployment process 240173.5k2](/packages/dragon-code-laravel-deploy-operations)[stayallive/laravel-eloquent-observable Register Eloquent model event listeners just-in-time directly from the model. 2928.9k7](/packages/stayallive-laravel-eloquent-observable) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)