1. 15 9月, 2012 7 次提交
    • J
      Split Open into Real and Savepoint · 6d9e6b3a
      Jon Leighton 提交于
      6d9e6b3a
    • J
      DRY · dd48f0ea
      Jon Leighton 提交于
      dd48f0ea
    • J
      Don't do the rollback in #commit · 58ced308
      Jon Leighton 提交于
      The caller needs to have knowledge of the rollback either way, so do it
      all in the caller (#transaction)
      58ced308
    • J
      Store the transaction number in the transaction object · 9296e693
      Jon Leighton 提交于
      This avoids us having to manually increment and decrement it.
      9296e693
    • J
      02f25a22
    • J
      Revert "create a transaction object and point AR objects at that object during a" · b89ffe7f
      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
      b89ffe7f
    • S
      Move queue classes to ActiveSupport · 8577687f
      Santiago Pastorino 提交于
      8577687f
  2. 14 9月, 2012 12 次提交
  3. 13 9月, 2012 21 次提交