How does Laravel Jobs get queued?

Image from: https://i0.wp.com/wp.laravel-news.com/wp-content/uploads/2020/01/queues-and-jobs.jpg

Previous article introduction

If you’re not aware of Laravel Event & Queue, you can check my article here. It’ll give you a brief of what each of these does and when to use what.

Laravel Queues & How does it gets into a driver?

To understand how Laravel Jobs gets into a queue driver, you’ll first need to know OOP. Let's check PHP Object’s lifecycle first.

PHP Object’s Lifecycle

When an object is created, it’ll automatically be destroyed by the PHP itself. The lifecycle of an object is limited to the scope it’s in. If it’s within a function (returns an object or processes object in that scope), it’ll be destroyed as soon as the function returns to its callee(1). If an object is created in global scope or call it a script, the objects will then be destroyed as soon as the script finished the execution. The PHP frees up the memory in the order the variables were created.

(1) is explained as

• If you return from the function and the function return is not stored anywhere then the object is instantly destroyed.
• If you return an object from the function, then store it in a variable even if you don’t use it, it’ll consume memory and will free the memory when the script finished execution.

Let’s check the following example.

In my script, I combined all the three scripts in one file. If you want to play with it, use multiple scripts. Read the comments in the code.

• In the script 1, $b1 is created.
• In script 2, $a12 is created.
• In script 3, get_a12() returns an object, but not stored in any variable.
• In script 3, get_b12() returns an object, but not stored in any variable.
• So for line 67, as the get_b12('s3') doesn’t keep the object in any variable, the object of B12 is instantly destroyed as soon as it’s returning from the function.

b12 — s3 on script 3 is destructed as soon as the function call exits

• First destructing script 3’s get_a12('s3'), then destructing script 3’s get_b12('s3'). None of them were stored in any variable. Then the script 3 ends, and PHP is freeing up the memory in order, which is destructing script 1’s $b12 and then script 2’s $a12.
• [R1] If you comment line #67 and uncomment #68, you’re storing the return value in a variable, which will be freed when the script finished execution. Check the image below.

b12 — s3 is destructed at the end, cause other objects were created earlier than the function call

• [R2] Now, first destructing script 3’s get_a12('s3') as not storing return value to any variable. Script 3 ends and then freeing up the memory in order as script 1’s $b12 and script 2’s $a12 and script 3’s variable $b2. Even if you didn’t use the variable, it used memory, thus destructing at the last moment.
• If you try the method chaining without storing the variable, with [R1]. The result will remain the same as [R1].
• If you unset a variable before the script finishes execution, then it calls __destruct itself.

in [R2] added unset($b2) immediate after #68

Now you know the PHP Object’s lifecycle. Cheers 🍻

Why does it matter with Laravel Jobs?

In Laravel, you can try multiple ways to put a job in a queue. If you use dispatch(new ALongRunningJob()); then going to that method declaration, you’ll find that it returns a PendingDispatch instance. And in that class, there is a __destruct method which puts the job ALongRunningJob::class to defined queue drivers.

To understand more, dig into Illuminate/Bus/BusServiceProvider.php and Illuminate/Queue/QueueServiceProvider.php and Illuminate/Queue/QueueManager.php and Illuminate/Bus/Dispatcher.php classes.

Happy coding ❤