Skip to content

Conversation

casperisfine
Copy link
Contributor

Ref: #50793

If we want to stop caching the checked out connections, then we must persist the cache in the pool, and assign it to the connection when it's checked out.

The pool become responsible for managing the cache lifecycle.

This also open the door to sharing the cache between multiple connections, which is valuable for read replicas, etc.

This change only really make sense if we go through with no longer caching checked out connections. Otherwise it's just extra complexity.

@casperisfine casperisfine force-pushed the refactor-query-cache-to-pool branch from bbf34f3 to f771d9b Compare February 12, 2024 09:05

private
def query_cache
@thread_query_caches.compute_if_absent(connection_cache_key(ActiveSupport::IsolatedExecutionState.context)) do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: we need to prune dead thread/fibers from this map, otherwise code that do queries from short lived threads or fibers would leak memory.

That's likely the reaper's job.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(or we should move that in ActiveSupport::IsolatedExecutionState.

@casperisfine casperisfine force-pushed the refactor-query-cache-to-pool branch from 9a8d06d to f864c6c Compare February 12, 2024 12:19
Ref: rails#50793

If we want to stop caching the checked out connections,
then we must persist the cache in the pool, and assign it
to the connection when it's checked out.

The pool become responsible for managing the cache lifecycle.

This also open the door to sharing the cache between multiple
connections, which is valuable for read replicas, etc.

This change only really make sense if we go through with no
longer caching checked out connections. Otherwise it's just
extra complexity.
Otherwise they could linger around and leak memory if a user
checkout connections from short lived fibers or threads.

The undocumented `connection_cache_key` hook point is eliminated
because it was essentially add to allow the connection pool to
be fiber based rather than thread based, which is now supported
out of the box.
@casperisfine casperisfine force-pushed the refactor-query-cache-to-pool branch from f864c6c to 94fc536 Compare February 14, 2024 09:57
@byroot byroot merged commit 13c1dfe into rails:main Feb 14, 2024
@casperisfine casperisfine deleted the refactor-query-cache-to-pool branch February 14, 2024 12:34
casperisfine pushed a commit to Shopify/rails that referenced this pull request Feb 21, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
casperisfine pushed a commit to Shopify/rails that referenced this pull request Feb 21, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
jenshenny pushed a commit to Shopify/rails that referenced this pull request Feb 23, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
gabriel-amaral pushed a commit to gabriel-amaral/rails that referenced this pull request Feb 27, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
jathayde pushed a commit to jathayde/rails that referenced this pull request Feb 28, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
Ridhwana pushed a commit to Ridhwana/rails that referenced this pull request Mar 7, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
viralpraxis pushed a commit to viralpraxis/rails that referenced this pull request Mar 24, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
fractaledmind pushed a commit to fractaledmind/rails that referenced this pull request May 13, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
xjunior pushed a commit to xjunior/rails that referenced this pull request Jun 9, 2024
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
yoones pushed a commit to yoones/rails that referenced this pull request Mar 6, 2025
Followup: rails#50938

The behavior changed to always clear the query cache as soon
as it's disabled, on the assumption that once queries have been
performed without it, all bets are off.

However that isn't quite true, we can apply the same clearing
logic than when it's enabled. If you perform read only queries
without the cache, there is no reason to clear it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants