This PR removes the functionality to call callbacks onto the caller thread (e.g. main thread), instead it has a dedicated background thread where these callbacks are performed. Previously the user would have to know to call Connection#flush in order to actually perform the callbacks, which just felt fragile and required some additional complexity in this lib. Now the complexity is reduced to a more traditional producer-consumer version and it’s the user’s responsibility to deal with processing responses from a different thread.
In our case this means that updating notification documents in the DB will be performed from a different thread. From some reading-up on Mongoid, it appears that Mongoid will automatically create a new session for different threads and seeing as Sidekiq runs on threads, I assume that this is already working fine?
@dblock @joeyAghion FYI
This PR removes the functionality to call callbacks onto the caller thread (e.g. main thread), instead it has a dedicated background thread where these callbacks are performed. Previously the user would have to know to call
Connection#flush
in order to actually perform the callbacks, which just felt fragile and required some additional complexity in this lib. Now the complexity is reduced to a more traditional producer-consumer version and it’s the user’s responsibility to deal with processing responses from a different thread.In our case this means that updating notification documents in the DB will be performed from a different thread. From some reading-up on Mongoid, it appears that Mongoid will automatically create a new session for different threads and seeing as Sidekiq runs on threads, I assume that this is already working fine?