Briefly, it spins up a background thread with a dedicated database connection and makes a blocking Postgres LISTEN query until results are returned, and then it forwards the result to other subscribing objects.
Hi, sorry to hijack this thread, but since you mentioned you're the author, I just wanted to ask you something. Do you have any plans to use a different locking mechanism other than the advisory lock? I'm asking because eventually every postgres-backed app that reaches a certain scale, requires a connection pooler (pgbouncer being the de-facto standard nowadays). We usually run pgbouncer in transaction mode, which doesn't support advisory locks. Any thoughts?
That was mentioned in another thread. I have two thoughts about it:
- Going off of my own experience, I've never used PgBouncer and I've worked on some moderately sized applications (1s of millions of users). So I could say "not in scope for the target use-case".
- It would be possible to add an argument option to use a transaction-based Advisory Lock instead. I can imagine that would have downsides (long-running transactions, yikes).
I'm imagining that the lifecycle of GoodJob is that people starting new projects might choose it, and then the feature set would grow with their needs.
The core reason I wrote it was to see how lean/simple I could write a database-backed ActiveJob adapter today. And hope
In practice any adapter should _just work_, but also all the other adapters pre-date ActiveJob (Rails 4.2) and Concurrent::Ruby (adopted in Rails 5.0 I think). The assumption is that building GoodJob on top of what already exists in Rails today, it can be performant (enough) and simple (easy to understand, maintain, keep compatible with new versions of Rails, etc). That's not a big claim, but maybe it's compelling.
Awesome! Thank you so much for the reasoning behind it. I haven't had a chance to look at Concurrent::Ruby but that _sounds_ like a pretty good reason all by itself!
As a big plus for a lot of folks who don't need absurd throughput, this makes for one less dependency by using the same db you already have. I'd be sold given the right use-case, thanks for sharing this, mate and _good job!_ ;)
I don't have much experience with PgBouncer. What's the scale/need when a team would use PgBouncer? That would help me prioritize supporting it better.
The main reason I can think of would be when you have hundreds of workers accessing a DB but the DB only has a small connection limit, say 200 or something. You can have the workers access the connection through pgBouncer to bring that up into the thousands.
GoodJob author here. The reason is that I don't have any production experience with Sidekiq.
My target right now is someone, like myself, who would typically spin up a new project with delayed_job or que, and provide a better alternative with GoodJob.
Maybe in the future I'll do some more research on understanding why someone might switch from a Sidekiq/Redis to not-Redis.
