I ran into an issue with a Laravel application I was working on. The issue was related to a long running job. The job generally takes between 10 to 15 minutes to complete.
Before the job kicked off we would change a value in the database to indicate the job was in progress – we’ll call this state as “active”. At the end of the job we would change the value in the database back – we’ll call this state “inactive”. Changing the record back would allow the record to be picked up by other jobs in the future.
At the end of the job (job still in progress) I could see the value as being set to “inactive” (as desired). However once the job was fully over – a peek into the database would show the record as “active” still. So during the job we would get a false positive of our database record being changed. After the job the record would “snap back” to an undesired state of “active”.
I tried multiple things to rectify this issue and get our database changes to stick after the job completed. One thing that worked – but felt “icky” – was chaining a job onto the main job to do database cleanup. Discovering that this chained job worked led me to discover that the DB::transaction was “locking” the record and preventing permanent changes. Once the DB::commit() line fired our “temporary” changes would go away.
In this instance it made more sense to not use a DB transaction method instead of chaining the job on. Especially since this job runs for so long. Hopefully this can help you identify similar issues in your long running jobs. The best course of action for your application might be different than my solution.
Good luck!