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.
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.
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.
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.