PDOException There is already an active transaction

Posted January 6, 2021 4.3k views

OS: Ubuntu 20
Platform: Laravel 8

Error Sample:
PDOException · There is already an active transaction
            try {
            } catch (Throwable $e) {

Kindly assist.

edited by bobbyiliev

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
2 answers

Hi there,

Can you share a code snippet of the method that you are using?

It looks like there is a database connection that is not being closed.


  • Hi Bobby,

    I kinda got a solution, still monitoring for success.
    So far so good.

    Changed my Supervisor settings from:

    command=php /path/to/myApp/artisan queue:work


    command=php /path/to/myApp/artisan queue:work database –sleep=3 –tries=3 –max-time=3600

    I have a feeling the ever running workers were filling up the systems space. Now they get shutdown after an hour and get started right up, relieving system space.

    I hope this also helps someone else.

    • Hi there,

      Happy to hear that you’ve got a working solution! And thank you for sharing this with the community.


    • Hello,

      I am also facing same type of error “There is already an active transaction”. But how you think that this issue is due to less system space. I am just trying to understand how the system space can cause the PDOException “There is already an active transaction”
      Please reply.

      • Hi anand2291,

        I have just started having the problems all over again…
        It must be a problem with my queue connection option which is ‘database’.

        • Hi there,

          It sounds like that your application is starting a transaction but not doing a commit or a rollback before the next thing tries to start a transaction.

          So it should look something like this:

          // You first start the transaction
          try {
              // Then you do your inserts
              // And commit
          } catch (\Exception $e) {
              // In case anything fails, then you do a rollback:

          Feel free to share a snippet of your code here if you wish.


          • Hi Bob,

            I haven’t really touched on anything to do with DB transactions.
            I have only set up the Supervisor to run the queue:work laravel command.
            And the command seems to be the originator of the problem.
            You can advise from where to get the code to check, which will mostly be laravel’s defaults.

          • Hello,

            The message we are getting “There is already an active transaction” is actually the effect of issue/exception happened before in the code execution. I tried checking the backtrace once this exception happening but not sure where it causing issue. This problem is happening sometimes very rare. Once or twice in a day. My ecommerce application is on Magento. So I am thinking how I can trace where exactly the origin of the problem.

            The backtrace we are getting is for “There is already an active transaction” is actually a effect of problem happened before somewhere execution. Checked for code changes etc but no luck.


          • Hi there,

            Indeed this is quite interesting. If it is the latest one, it might be a good idea to submit an issue to the official Laravel repo.

            What I could suggest is giving Redis a try as the Queue driver to see how it goes compared to the current situation.

            Let me know how it goes!

          • Hi Bob,

            I have decided to run my queues using redis instead.
            The errors never resolved.


          • Hi there @danielrey,

            How are things looking with Redis?


      • I got the opinion on system resources from laravel docs:

        The –max-time option may be used to instruct the worker to process jobs for the given number of seconds and then exit. This option may be useful when combined with Supervisor so that your workers are automatically restarted after processing jobs for a given amount of time, releasing any memory they may have accumulated:

        • Hi Bob,

          I have made the following additional changes on mysql:

          innodblogfilesize = 128M
          allowed_packet = 128M

          Monitoring for improvement.
          Everything was in their defaults.

          • Hi there @danielrey,

            Indeed this would make sense! I could suggest checking your syslogs and MySQL logs for some extra information too.

            Let me know how it goes after the adjustments.


          • Hi @bobbyiliev ,

            Let me monitor it for about 5-7 days.
            I’ll then give feedback.


          • Hey @danielrey, any new experiences with the problem? Solutions? I have the same problem and thanks to this thread I have at least found the workaround of restarting the queue. The system in the setup was previously running without problems at a hoster, then the software was moved to a new system and now the problem occurred.

Changed from database queues to horizon for my Laravel backend. So far so good. No more errors like before.