Summary of several common errors in Laravel usage

I have used the Laravel framework for a period of time and encountered many problems during this period. It is not easy to debug some of them. In this article, I will find a few examples. If you can avoid detours, then I will not write it in white.

Error: "Can't swap PDO instance while within transaction 」
By querying the Laravel source code, you can confirm that the exception is 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 is switched when the transaction is enabled. However, sometimes this error may occur even if the database connection is not explicitly switched in the code. For example, when an error occurs when a query statement is executed, the system will use the tryAgainIfCausedByLostConnection method to determine whether the problem is caused by a lost connection. If yes, the system will reconnect through The reconnect method, during the reconnection, the system will execute some cleanup operations through the disconnect method, in which the setPdo method is called.

After clarifying the cause and effect, you will naturally know how to solve the problem: check the network condition and confirm the cause of database connection loss. This may be caused by a device problem or improper timeout settings. A relative dirty method is to execute the DB: reconnect () method to reconnect to the database before the query.

Error: "Cannot delete job <ID>: NOT_FOUND 」
This problem does not actually have much to do with Laravel, but is caused by Beanstalk.

-Beanstalk
To solve this problem, you must first understand the life cycle of a message: when a message is put into the queue, it enters the READY state. At the same time, it is associated with a TTR (time to run) Timer, indicating the time the message is allowed to run. When the message is consumed, it enters the RESERVED state. After consumption, the message will be deleted. If the consumption time is longer than that of TTR, the system will think that the consumer has crashed and then the message will be returned from the RESERVED status to the READY status, to another consumer. Therefore, the same message may be processed by multiple consumers. The first processed consumer can delete the message normally, and the other consumers will report an error that cannot be deleted when deleting the message.

The solution is simple. First, make sure that TTR settings are not too small. Second, Beanstalk provides a special touch command to solve the problem of too long execution time, in some cases, we may need to lock the application layer to avoid the situation where the same message is simultaneously processed by multiple consumers.

Error: "No query results for model 」
When Laravel read/write splitting is activated, the consumer may receive similar errors when processing messages. A queue command with potential problems is 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 Laravel read/write splitting is enabled, find may not be able to query the corresponding data because of the master/slave Latency. Once we analyze the data here, it is very likely that the writing method will be changed to the following:

<? 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
    }
}

?> That is to say, the query is fixed on the master server through Laravel's onWriteConnection method, but it is actually invalid. The crux of the problem is that during deserialization, the system will call findOrFail on the slave server.

<? Php

Protected function getRestoredPropertyValue ($ value)
{
Return $ value instanceof ModelIdentifier
? (New $ value-> class)-> findOrFail ($ value-> id): $ value;
}

?> Because we cannot HACK into the framework, onWriteConnection is meaningless. In fact, if you look at the problem from another perspective, you only need to ensure that you do not use database objects as attributes during serialization:

<? 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 );
    }
}

?> The above are some representative errors I have encountered. You are welcome to join us.