- 15 9月, 2012 1 次提交
-
-
由 Jon Leighton 提交于
This reverts commit c24c8852. 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
-
- 08 9月, 2012 1 次提交
-
-
由 Aaron Patterson 提交于
transaction.
-
- 25 8月, 2012 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 21 8月, 2012 3 次提交
-
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
- 17 6月, 2012 1 次提交
-
-
由 Dylan Smith 提交于
-
- 31 5月, 2012 1 次提交
-
-
由 Jeremy Kemper 提交于
-
- 11 4月, 2012 1 次提交
-
-
由 Rafael Mendonça França 提交于
Closes #5202 and #919
-
- 03 4月, 2012 1 次提交
-
-
由 Waseem Ahmad 提交于
-
- 01 4月, 2012 1 次提交
-
-
由 Doug Cole 提交于
-
- 28 2月, 2012 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 22 2月, 2012 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 09 12月, 2011 1 次提交
-
-
由 Vijay Dev 提交于
-
- 16 8月, 2011 5 次提交
-
-
由 Jon Leighton 提交于
-
由 Jon Leighton 提交于
-
由 Jon Leighton 提交于
-
由 Jon Leighton 提交于
-
由 Jon Leighton 提交于
-
- 09 8月, 2011 1 次提交
-
-
由 Jon Leighton 提交于
Make it the responsibility of the connection to hold onto an ARel visitor for generating SQL. This improves the code architecture generally, and solves some problems with marshalling. Adapter authors please take note: you now need to define an Adapter.visitor_for method, but it degrades gracefully with a deprecation warning for now.
-
- 25 5月, 2011 1 次提交
-
-
由 Josh Kalderimis 提交于
-
- 24 5月, 2011 1 次提交
-
-
由 Sebastian Martinez 提交于
-
- 10 5月, 2011 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 01 5月, 2011 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 30 4月, 2011 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 25 4月, 2011 1 次提交
-
-
由 Ken Collins 提交于
-
- 22 4月, 2011 1 次提交
-
-
由 Ken Collins 提交于
-
- 15 4月, 2011 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 23 3月, 2011 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 18 3月, 2011 1 次提交
-
-
由 Paco Guzman 提交于
-
- 12 2月, 2011 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 10 2月, 2011 1 次提交
-
-
由 Ken Collins 提交于
-
- 09 2月, 2011 1 次提交
-
-
由 Aaron Patterson 提交于
This fixes CVE-2011-0448
-
- 04 1月, 2011 2 次提交
-
-
由 Raimonds Simanovskis 提交于
otherwise when using external ActiveRecord adapters (e.g. Oracle) database_statements might be loaded before active_support/core_ext/module/deprecation which results in NoMethodError (commit 60cf65de added "deprecate" call to database_statements.rb)
-
由 Aaron Patterson 提交于
-
- 06 11月, 2010 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 27 10月, 2010 4 次提交
-
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-