-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Releasing connections in ActiveRecord 7.1+ #82
Comments
Probably caused by these changes? rails/rails@42fede5 |
hey @efibootmgr, thank you for the suggestion! |
After some researching and help of Claude 3.5 hallucinations and intensive reverse prompting, i came back with this. Claude also suggested some fix, and why not, i will also post it below. Low chance it may help, but |
rails/rails@b36f918 |
The Claude said: Here's an approach to fix this issue in Rage:
This solution addresses the changes introduced by the commit by:
This approach should resolve the issues caused by the SchemaCache refactoring while maintaining compatibility with Rage's fiber-based concurrency model. Make sure to thoroughly test this solution in your environment, especially under various load conditions and with different types of database operations. The code may be wrong, but he must be definitely right lmao. I suggest you to check on this issue before releasing websockets. I'm not using Action Cable, but instead trying combination of Crystal based websocket server and LavinMQ. But I'm sure that addition of Action Cable websockets will help with smaller projects. |
woah, this is wild!! Looking into it! |
Hey @efibootmgr The Rails issue is not fixed yet, but we've reworked the way we release AR connections. The new approach is compatible with AR 6.0+ and it will go into v1.10.0 - see #103. Thank you for your input! Couldn't have happened without you! |
The ActiveRecord connection pool is designed so that if a thread (or a fiber) checks out a connection, the connection will remain attached to this thread until the server has finished processing the request.
This makes sense in a threaded environment but doesn't make sense for Rage. Consider the following code:
This code makes a request to the DB (
ApiToken.exist?
) and then sends an HTTP request. In Rails, the ActiveRecord connection, checked out with theApiToken.exist?
call, will remain attached to the thread which performs the request until the action (and consequently the HTTP request) has finished.However, this doesn't make sense for Rage - while the current fiber is paused, waiting for the HTTP request to finish, other fibers could use the DB connection. Hence, we need to release ActiveRecord connections not once the whole action has finished but once a DB request has been completed.
Rage implements this using the Fiber.defer method. Unfortunately, something has changed in ActiveRecord 7.1, and while this approach works in ActiveRecord 7.0.8.1, it doesn't work reliably in ActiveRecord 7.1 anymore and thus has been disabled.
Goal: Make changes to allow releasing DB connections once a DB request has completed with ActiveRecord 7.1+.
Errors:
The text was updated successfully, but these errors were encountered: