Thanks for helping me understand. I didn't understand how exactly AR's rack middleware doesn't have the same problem, the key thing I was missing was the per-session nature of the timeout.
Yeah, while Sequel's way still seems cleaner to me, I now understand better why Active Record maintainers went that route. Yeah, the server_block extension would probably allow for easy creation of a similar Rack middleware for Sequel. Btw, I gained new appreciation for Sequel once I dove into the primary/replica & sharding code, I haven't read that part of the codebase so far. I really like how primaries, replicas, and shards are all treated the same internally by components like the connection pool (with the exception of :default and :read_only servers having special meaning), it makes things much easier to reason about. Kind regards, Janko On Wednesday, November 4, 2020 at 7:14:20 PM UTC+1 Jeremy Evans wrote: > On Wed, Nov 4, 2020 at 12:22 AM Janko Marohnić <[email protected]> > wrote: > >> Hi everyone, >> >> I'm comparing a bit Active Record's implementation of primary/replica >> selection with Sequel. Active Record requires you to manually switch the >> connection to a replica, and has a Rack middleware that can do this >> switching based on HTTP verbs, which I'm very skeptical about. >> >> On the Ruby Day conference, I asked Eileen why didn't GitHub go the route >> of having Active Record automatically use replica for reads (like Sequel), >> and the answer was that it was due to the replication lag, where the newly >> updated data will not be immediately available on the replica, so it's >> dangerous to write something to a primary and then try to immediately read >> it from a replica. >> >> If this is really the general case, does that make Sequel's approach of >> automatically using replica for reads less useful? I still like Sequel's >> approach much better, I just want to better understand the trade-offs. >> > > You are correct, it's a tradeoff. With Sequel's design and a > primary/replica setup, a read query directly after a write query outside of > a transaction may not see the updated value. IIRC, the Rails rack > middleware bases the decision on whether to use the primary on a timeout > from when the last POST (or similar non-idempotent request method) was > used. So directly after a POST, the same session will use the primary and > see up-to-date data, but other sessions would still see stale data from the > replica until it is caught up. > > Considering that ActiveRecord focuses on being used only inside Rails, > where the rack middleware is used by default, it seems a good tradeoff. > Sequel has a more general focus, not being restricted to web requests, and > I think Sequel's default makes sense. I'm guessing it wouldn't be too hard > to copy the Rails middleware and modify it to support Sequel if you wanted > similar behavior to Rails inside web requests. > > Thanks, > Jeremy > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/a142e8ce-f1af-4cdf-89d9-c1ddfe8a4416n%40googlegroups.com.
