Currently, the configuration is being stored as a class level variable.
That renders the gem thread unsafe. This might be OK if you're using it from rails
on a simple setup with single threaded requests, But if you're running multi-threaded
rack servers like Puma or Thin, or even a background job processor like Sidekiq, you might
run into trouble.
This change consists into storing the configuration on Thread.current instead of a class variable.
The choice for the request_store gem makes sense since it provides a rack middleware to clear
Current.thread after each request.
I understand that this might be an issue since some people are probably configuring the gem on a initializer instead of doing it at a request level. But if you have more than one ChargeBee site (as I imagine most people will) and you call ChargeBee.configure on each request, this change will not affect you at all.
Currently, the configuration is being stored as a class level variable. That renders the gem thread unsafe. This might be OK if you're using it from rails on a simple setup with single threaded requests, But if you're running multi-threaded rack servers like Puma or Thin, or even a background job processor like Sidekiq, you might run into trouble.
This change consists into storing the configuration on
Thread.currentinstead of a class variable. The choice for therequest_storegem makes sense since it provides a rack middleware to clearCurrent.threadafter each request.I understand that this might be an issue since some people are probably configuring the gem on a initializer instead of doing it at a request level. But if you have more than one ChargeBee site (as I imagine most people will) and you call
ChargeBee.configureon each request, this change will not affect you at all.