In a previous episode we looked into using the withoutOverlapping job middleware to prevent multiple instances of the same job from running at the same time. That middleware works by releasing instances of the job back to the queue if there is already an instance being processed. Those released instances will eventually get processed, or fail if they were released too many times and exceeded the allowed number of tries. That means using the withoutOverlapping middleware there may be multiple instances of the same job in the queue even if they are not going to be processed at the same time. What if we want to prevent having multiple instances of the same job in the queue?

time. What if we want to prevent having multiple instances of the same job in the queue? For that we may configure job uniqueness by implementing the ShouldBeUnique interface. So let's command the middleware here and implement the ShouldBeUnique interface. So this interface is under Illuminate\Contracts\Queue\ShouldBeUnique. Now let's go to the terminal and dispatch the job multiple times to see if it was added to the queue. So one, two, three, we dispatched it three times. Now if we check sqlpro we will find only one instance of the job in the queue even though we pushed it multiple times.

Now if we check sqlpro we will find only one instance of the job in the queue even though we pushed it multiple times. Laravel detected that the should-be-unique interface was implemented on the job and prevented putting the job in the queue because there is already an instance of the job. By default Laravel uses the job class name as the unique key. We can use a custom key by implementing a uniqueId method inside the job class. So we can go and implement a public method called uniqueId. And return the name of the log that's going to be used. So here we're going to return deployments. Under the hood Laravel creates a lock to prevent pushing the same job to the queue if there

So here we're going to return deployments. Under the hood Laravel creates a lock to prevent pushing the same job to the queue if there is already an instance there. We can also configure how long the unique lock should be alive. That lock is released automatically when the job currently in the queue is processed. But if anything went wrong and the lock wasn't released this could lead to all future dispatches of the job getting it ignored. To prevent this we may configure the expiration time for the unique lock by adding a uniqueFor public method on the job class. So similar to uniqueId we're going to implement a public method called uniqueFor.

for public method on the Job class. So similar to uniqueId we're going to implement a public method called unique for. And then return the number of seconds the job should be unique for. So here we're implementing 60 seconds. So far so good. The shouldBeUnique interface prevents dispatching until instance that's existing in the queue finishes processing. Or it's going to release the lock automatically after 60 seconds so the queue can accept more instance of the Job. But what if we want to prevent dispatching until the existing instance starts processing.

instance of the job. But what if we want to prevent dispatching until the existing instance starts processing not when it finishes processing. For that we may use the shouldBeUniqueUntilProcessing interface instead. So instead of shouldBeUnique we should use shouldBeUniqueUntilProcessing. And that should take care of it. Perfect, so far we have covered multiple ways we can control job concurrency and throttling. These were all general examples to see how things can be configured. If you want to see real world examples make sure to check Laravel Queues in action. It's an ebook I published in 2020 and I keep it up to date with the latest Laravel changes.

If you want to see real world examples make sure to check Laravel Queues in action. It's an ebook I published in 2020 and I keep it up to date with the latest Laravel changes. Check it out at learnlaravelqueues.com. Alright let's take a look at another useful middleware that you can use with your jobs. It's called the ThrottlesExceptions middleware. Let's first clean our job by removing these methods and remove the interface here. Now our job is clean and let's implement the ThrottlesExceptions middleware. So new ThrottlesExceptions. This middleware acts as a circuit breaker around your job that delays processing if it is failing too often.

This middleware acts as a circuit breaker around your job that delays processing if it is failing too often. You can define the number of consecutive failures you want this middleware to allow. Once this number is hit the middleware is going to release instances of this job back to the queue immediately once a worker picks it up. This can be useful if your job interacts with a third party service that went down temporarily. The middleware will prevent reaching this service by not running any job if our attempts fail for 10 consecutive times. So let's implement 10 here. If this job fails for 10 consecutive times the middleware will prevent new instance of

So let's implement 10 here. If this job fails for 10 consecutive times the middleware will prevent new instance of the job from running. This will give a chance to the third party service to recover before we can reach it again. It's a handy way to prevent overwhelming our system while a third party service it relies on experiences an outage.