So my use case was basically scheduling emails for every 1st day of a month, and I wanted it to be able to whenever you start an application (imagine you just deployed the first time) and it would create the job for doing the actual delivery to sendgrid with a scheduled at. The problem was the sendgrid email has to be sent close to the sending deadline because theoretically users might had sign up anytime before the scheduling and you would still want them to receive the email no matter what, so fetching what users to deliver to has to be postponed to an hour or 2 of the email going off.
And then the sendgrid request had to account for any arbitrary number of delivery targets and in order to prevent a gigantic http request (because of the data points being sent for the templates being partially unique and partially shared but the shared parts still having to be included in each data_for_template item), it has to batch the delivery.
Then months have this weird peculiarity that they have different days length. So if a job was scheduled at the first of Jan, to be delivered on the first of Feb, there would be a uniqueness period of 31 days, but then of Feb, that period would be different, and I would need to convolute the logic in order to guarantee working periods I guess? It seemed complex to do (or more complex than I wanted).
So I made that transaction thing, creating a table for the locks with just a primary key which is the lock identifier itself.
Basically
|> Multi.insert(:job_lock, %Lock{id: "lock_some_identifier_01_01_2020"})
|> Multi.run(:job, fn(_, _) -> do_oban_insert(params) end)
|> Multi.insert(:job_lock_to_keep, %Lock{id: "scheduled_some_identifier_01_01_2020"})
|> Multi.delete(:delete_job_lock.....)
|> Repo.transaction()
Probably I could rely on just leaving the first “job_lock” and not doing the second one afterwards.
The do_oban_isert schedules the job to be run on wtv time.
Then the job worker picks it up and tries to deliver the thing in batches, for each batch it creates another two jobs in a transaction, one to fetch the next batch and other to deliver for the current batch, so that you don’t have mid batch failures restarting the whole thing and duplicate emails being sent, etc, if the job for the batch fails being inserted, only the insertion of that job is repeated, etc.
I might be wrong but this ended up appearing to me to be the best way to guarantee no duplication of email sending without having to fiddle with time periods, since the lock identifiers are reproducible at any point in time.
I’ve read the xact lock link, but how does that work? Is it a lock that is not temporary?
