Common errors and solutions in Laravel _javascript tips

One, the error: "can ' t swap PDO instance while within transaction"

By querying the Laravel source code, you can confirm that the exception was thrown in the setPdo method:

<?php Public

function Setpdo ($pdo)
{
  if ($this->transactions >= 1) {
    throw new RuntimeException ("
      Can" T swap PDO instance while within transaction.
    ");
  }

  $this->pdo = $pdo;

  return $this;

>

Literally, this error occurs because the database connection has been switched on when the transaction is turned on. Sometimes, however, this error can occur even if there is no explicit switch to the database connection in the code. For example, when executing a query statement error, the system will tryAgainIfCausedByLostConnection determine the problem is caused by the loss of connectivity, if it is, then the system will be reconnected through the reconnect method, when reconnecting, the system will disconnect perform some cleanup work, which calls the setPdo method.

Clear the cause and consequence, naturally know how to solve the problem: Check the network situation, confirm the reason for the loss of the database connection, this may be a device problem, may be timeout caused by improper settings. A relative approach dirty is to perform a method before the query to DB::reconnect() reconnect the database.

Second, the error: "cannot Delete job:not_found"

This problem does not really have much to do with Laravel, but the queue service Beanstalk.

Beanstalk

To solve this problem, you need to understand the lifecycle of a message: When a message is placed in a queue, it enters the READY state, and at the same time it associates a TTR（time to run） timer that indicates the time that this message is allowed to run, and when it is consumed, it enters a RESERVED state, and after consumption is finished, This message will be deleted, if the consumption time is too long, TTR then the system will think that the consumer has been hung, which will then return the message from the RESERVED state to the READY state, to another consumer to deal with. The same message may be processed by more than one consumer, and the first customer who finishes the process can delete the message normally, while the rest of the consumer will report an error that cannot be deleted when the message is deleted.

The solution is simple, first of all, the need to ensure that TTR the settings are not too small, and secondly, actually Beanstalk provides a special touch command to solve the problem of too long execution time, in addition, There are times when we may need to use locking at the application level to circumvent the same message being handled by multiple consumers at the same time.

Third, the error: "no query results for model"

In the context of activating Laravel read-write separation, a similar error may be received when the consumer processes messages. A queue command with a potential problem is probably as follows:

<?php

class Foo extends Command implements Selfhandling, shouldbequeued
{use
  interactswithqueue, Serializesmodels;

  protected $bar;

  Public function __construct ($id)
  {
    $this->bar = Bar::find ($id);
  }

  Public function handle ()
  {
    //$this->bar
  }
}

?>

Obviously, when the laravel read and write separation is turned on, because of the master-slave delay, it find may not be able to query the corresponding data, once we analyze here, then it is likely to change the wording to the following look:

<?php

class Foo extends Command implements Selfhandling, shouldbequeued
{use
  interactswithqueue, Serializesmodels;

  protected $bar;

  Public function __construct ($id)
  {
    $this->bar = bar::onwriteconnection ()->find ($id);
  }

  Public function handle ()
  {
    //$this->bar
  }
}

?>

In other words, the onWriteConnection query is fixed to the primary server by Laravel, but it is not actually valid. The crux of the problem is that when deserializing, the system is invoked from the server one time findOrFail .

<?php

protected function Getrestoredpropertyvalue ($value)
{return
  $value instanceof Modelidentifier
    ? (New $value->class)->findorfail ($value->id): $value;
}

? >

Because we can't HACK get inside the frame, onWriteConnection it makes no sense. In fact, change the point of view, as long as the serialization, to ensure that the database objects do not use the attributes can:

<?php

class Foo extends Command implements Selfhandling, shouldbequeued
{use
  interactswithqueue, Serializesmodels;

  protected $id;

  Public function __construct ($id)
  {
    $this->id = $id;
  }

  Public function handle ()
  {
    $bar = bar::onwriteconnection ()->find ($this->id);
  }

? >

Iv. Summary

The above is I encountered in the use of Laravel several representative of the error and solutions, if there are questions to welcome everyone to communicate. Hope this article for everyone's study or work can bring certain help.