| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
The caller needs to have knowledge of the rollback either way, so do it
all in the caller (#transaction)
|
| | |
| |
| |
| | |
This avoids us having to manually increment and decrement it.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
during a"
This reverts commit c24c885209ac2334dc6f798c394a821ee270bec6.
Here's the explanation I just sent to @tenderlove:
Hey,
I've been thinking about about the transaction memory leak thing that we
were discussing.
Example code:
post = nil
Post.transaction do
N.times { post = Post.create }
end
Post.transaction is going to create a real transaction and there will
also be a (savepoint) transaction inside each Post.create.
In an idea world, we'd like all but the last Post instance to be GC'd,
and for the last Post instance to receive its after_commit callback when
Post.transaction returns.
I can't see how this can work using your solution where the Post itself
holds a reference to the transaction it is in; when Post.transaction
returns, control does not switch to any of Post's instance methods, so
it can't trigger the callbacks itself.
What we really want is for the transaction itself to hold weak
references to the objects within the transaction. So those objects can
be GC'd, but if they are not GC'd then the transaction can iterate them
and execute their callbacks.
I've looked into WeakRef implementations that are available. On 1.9.3,
the stdlib weakref library is broken and we shouldn't use it.
There is a better implementation here:
https://github.com/bdurand/ref/blob/master/lib/ref/weak_reference/pure_ruby.rb
We could use that, either by pulling in the gem or just copying the code
in, but it still suffers from the limitation that it uses ObjectSpace
finalizers.
In my testing, this finalizers make GC quite expensive:
https://gist.github.com/3722432
Ruby 2.0 will have a native WeakRef implementation (via
ObjectSpace::WeakMap), hence won't be reliant on finalizers:
http://bugs.ruby-lang.org/issues/4168
So the ultimate solution will be for everyone to use Ruby 2.0, and for
us to just use ObjectSpace::WeakMap.
In the meantime, we have basically 3 options:
The first is to leave it as it is.
The second is to use a finalizer-based weakref implementation and take
the GC perf hit.
The final option is to store object ids rather than the actual objects.
Then use ObjectSpace._id2ref to deference the objects at the end of the
transaction, if they exist. This won't stop memory use growing within
the transaction, but it'll grow more slowly.
I benchmarked the performance of _id2ref this if the object does or does
not exist: https://gist.github.com/3722550
If it does exist it seems decent, but it's hugely more expensive if it
doesn't, probably because we have to do the rescue nil.
Probably most of the time the objects will exist. However the point of
doing this optimisation is to allow people to create a large number of
objects inside a transaction and have them be GC'd. So for that use
case, we'd be replacing one problem with another. I'm not sure which of
the two problems is worse.
My feeling is that we should just leave this for now and come back to it
when Ruby 2.0 is out.
I'm going to revert your commit because I can't see how it solves this.
Hope you don't mind... if I've misunderstood then let me know!
Jon
|
| |
|
|
|
| |
1. Unused variable
2. possibly useless use of a variable in
void context
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a result of different commits, ConnectionPool had become
of two minds about exceptions, sometimes using PoolFullError
and sometimes using ConnectionTimeoutError. In fact, it was
using ConnectionTimeoutError internally, but then recueing
and re-raising as a PoolFullError.
There's no reason for this bifurcation, standardize on
ConnectionTimeoutError, which is the rails2 name and still
accurately describes semantics at this point.
History
In Rails2, ConnectionPool raises a ConnectionTimeoutError if
it can't get a connection within timeout.
Originally in master/rails3, @tenderlove had planned on removing
wait/blocking in connectionpool entirely, at that point he changed
exception to PoolFullError.
But then later wait/blocking came back, but exception remained
PoolFullError.
Then in 02b233556377 pmahoney introduced fair waiting logic, and
brought back ConnectionTimeoutError, introducing the weird bifurcation.
ConnectionTimeoutError accurately describes semantics as of this
point, and is backwards compat with rails2, there's no reason
for PoolFullError to be introduced, and no reason for two
different exception types to be used internally, no reason
to rescue one and re-raise as another. Unify!
|
| |\
| |
| |
| |
| | |
Conflicts:
activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb
|
| | | |
|
| |/
|
|
| |
transaction.
|
| | |
|
| |
|
|
| |
We don't need separate @class_to_pool and @connection_pool hashes.
|
| | |
|
| |
|
|
|
|
| |
* Loop rather than recurse in retrieve_connection_pool
* Key the hash by class rather than class name. This avoids creating
unnecessary strings.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It has been moved to active_record_deprecated_finders.
Use #to_a instead.
|
| | |
|
| |
|
|
|
|
|
| |
Commit 3dbedd2 added NOT NULL constraints to timestamps.
Commit fcef728 started to revert this, but was incomplete.
With this commit, 3dbedd2 should be fully reverted and
timestamps will no longer default to NOT NULL.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For instance, running
rails g migration CreateMediaJoinTable artists musics:uniq
will create a migration with
create_join_table :artists, :musics do |t|
# t.index [:artist_id, :music_id]
t.index [:music_id, :artist_id], unique: true
end
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Introduced in 75b340d1a4bcf2f1233fb65a15ff6b8059e2230e
|
| | |
| |
| |
| | |
Fixes #867
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch fixes quoting for ActiveSupport::Duration instances:
# before
>> ActiveRecord::Base.connection.quote 30.minutes
=> "'--- 1800\n...\n'"
# after
>> ActiveRecord::Base.connection.quote 30.minutes
=> "1800"
Also, adds a test for type casting ActiveSupport::Duration instances.
Related to #1119.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Examples:
add_reference :products, :supplier, polymorphic: true, index: true
remove_reference :products, :user
`add_belongs_to` and `remove_belongs_to` are
acceptable.
|
| |/
|
|
| |
Also fix failures in check options for nil
|
| | |
|
| | |
|
| |
|
|
|
| |
Get rid of ActiveModel::Configuration, make better use of
ActiveSupport::Concern + class_attribute, etc.
|
| |\
| |
| |
| |
| |
| |
| | |
Fair connection pool2
Conflicts:
activerecord/test/cases/associations/eager_test.rb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The core of this fix is a threadsafe, fair Queue class. It is
very similar to Queue in stdlib except that it supports waiting
with a timeout.
The issue this solves is that if several threads are contending for
database connections, an unfair queue makes is possible that a thread
will timeout even while other threads successfully acquire and release
connections. A fair queue means the thread that has been waiting the
longest will get the next available connection.
This includes a few test fixes to avoid test ordering issues that
cropped up during development of this patch.
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#6441
An AR ConnectionSpec `wait_timeout` is pre-patch used for three
different things:
* mysql2 uses it for MySQL's own wait_timeout (how long MySQL
should allow an idle connection before closing it), and
defaults to 2592000 seconds.
* ConnectionPool uses it for "number of seconds to block and
wait for a connection before giving up and raising a timeout error",
default 5 seconds.
* ConnectionPool uses it for the Reaper, for deciding if a 'dead'
connection can be reaped. Default 5 seconds.
Previously, if you want to change these from defaults, you need
to change them all together. This is problematic _especially_
for the mysql2/ConnectionPool conflict, you will generally _not_
want them to be the same, as evidenced by their wildly different
defaults. This has caused real problems for people #6441 #2894
But as long as we're changing this, forcing renaming the
ConnectionPool key to be more specific, it made sense
to seperate the two ConnectionPool uses too -- these two
types of ConnectionPool timeouts ought to be able to be
changed independently, you won't neccesarily want them
to be the same, even though the defaults are (currently)
the same.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d2901f0fc4270a765717ad572d559dc49a56b3a8, reversing
changes made to 525839fdd8cc34d6d524f204528d5b6f36fe410c.
Conflicts:
activerecord/test/cases/connection_pool_test.rb
Reason: This change broke the build (http://travis-ci.org/#!/rails/rails/builds/1391490)
and we don't have any solution until now. I asked the author to try to
fix it and open a new pull request.
|
| | |
|
| |
|
|
| |
concurrency error.
|
