2004-11-23 20:04:44 -05:00
module ActiveRecord
2008-10-05 17:16:26 -04:00
# See ActiveRecord::Transactions::ClassMethods for documentation.
module Transactions
2009-05-28 12:35:36 -04:00
extend ActiveSupport :: Concern
2014-12-19 18:21:43 -05:00
#:nodoc:
2012-12-25 13:35:52 -05:00
ACTIONS = [ :create , :destroy , :update ]
2009-05-11 22:23:47 -04:00
2010-06-08 16:59:06 -04:00
included do
2013-05-14 19:03:09 -04:00
define_callbacks :commit , :rollback ,
2015-02-13 21:10:53 -05:00
:before_commit ,
:before_commit_without_transaction_enrollment ,
2015-02-12 23:06:44 -05:00
:commit_without_transaction_enrollment ,
:rollback_without_transaction_enrollment ,
2013-05-14 19:03:09 -04:00
scope : [ :kind , :name ]
2010-06-08 16:59:06 -04:00
end
2010-11-28 10:55:48 -05:00
2010-06-16 13:55:15 -04:00
# = Active Record Transactions
#
2008-10-05 17:16:26 -04:00
# Transactions are protective blocks where SQL statements are only permanent
# if they can all succeed as one atomic action. The classic example is a
# transfer between two accounts where you can only have a deposit if the
# withdrawal succeeded and vice versa. Transactions enforce the integrity of
# the database and guard the data against program errors or database
# break-downs. So basically you should use transaction blocks whenever you
# have a number of statements that must be executed together or not at all.
2010-06-16 13:55:15 -04:00
#
# For example:
2004-11-23 20:04:44 -05:00
#
2008-10-05 17:16:26 -04:00
# ActiveRecord::Base.transaction do
2004-11-23 20:04:44 -05:00
# david.withdrawal(100)
# mary.deposit(100)
# end
#
2010-05-01 18:40:31 -04:00
# This example will only take money from David and give it to Mary if neither
# +withdrawal+ nor +deposit+ raise an exception. Exceptions will force a
# ROLLBACK that returns the database to the state before the transaction
# began. Be aware, though, that the objects will _not_ have their instance
2008-10-05 17:16:26 -04:00
# data returned to their pre-transactional state.
2004-11-23 20:04:44 -05:00
#
2008-05-25 07:29:00 -04:00
# == Different Active Record classes in a single transaction
2007-11-06 14:04:54 -05:00
#
2008-05-25 07:29:00 -04:00
# Though the transaction class method is called on some Active Record class,
2007-11-06 14:04:54 -05:00
# the objects within the transaction block need not all be instances of
2008-10-05 17:16:26 -04:00
# that class. This is because transactions are per-database connection, not
# per-model.
#
2010-05-01 18:40:31 -04:00
# In this example a +balance+ record is transactionally saved even
# though +transaction+ is called on the +Account+ class:
2007-11-06 14:04:54 -05:00
#
# Account.transaction do
2007-11-06 14:11:42 -05:00
# balance.save!
# account.save!
2007-11-06 14:04:54 -05:00
# end
#
2010-05-01 18:40:31 -04:00
# The +transaction+ method is also available as a model instance method.
# For example, you can also do this:
2008-10-05 17:16:26 -04:00
#
# balance.transaction do
# balance.save!
# account.save!
# end
#
2004-11-23 20:04:44 -05:00
# == Transactions are not distributed across database connections
#
2010-05-01 18:40:31 -04:00
# A transaction acts on a single database connection. If you have
2004-11-23 20:04:44 -05:00
# multiple class-specific databases, the transaction will not protect
2010-05-01 18:40:31 -04:00
# interaction among them. One workaround is to begin a transaction
2004-11-23 20:04:44 -05:00
# on each class whose models you alter:
#
# Student.transaction do
# Course.transaction do
# course.enroll(student)
# student.units += course.units
# end
# end
#
2010-05-01 18:40:31 -04:00
# This is a poor solution, but fully distributed transactions are beyond
2004-11-23 20:04:44 -05:00
# the scope of Active Record.
#
2010-05-01 18:40:31 -04:00
# == +save+ and +destroy+ are automatically wrapped in a transaction
2004-11-23 20:04:44 -05:00
#
2010-05-01 18:40:31 -04:00
# Both +save+ and +destroy+ come wrapped in a transaction that ensures
# that whatever you do in validations or callbacks will happen under its
2010-06-08 15:41:42 -04:00
# protected cover. So you can use validations to check for values that
2010-05-01 18:40:31 -04:00
# the transaction depends on or you can raise exceptions in the callbacks
# to rollback, including <tt>after_*</tt> callbacks.
#
# As a consequence changes to the database are not seen outside your connection
# until the operation is complete. For example, if you try to update the index
# of a search engine in +after_save+ the indexer won't see the updated record.
# The +after_commit+ callback is the only one that is triggered once the update
# is committed. See below.
2004-11-23 20:04:44 -05:00
#
2008-07-28 07:26:59 -04:00
# == Exception handling and rolling back
2004-11-23 20:04:44 -05:00
#
2008-10-05 17:16:26 -04:00
# Also have in mind that exceptions thrown within a transaction block will
# be propagated (after triggering the ROLLBACK), so you should be ready to
# catch those in your application code.
2008-07-28 07:26:59 -04:00
#
2010-05-01 18:40:31 -04:00
# One exception is the <tt>ActiveRecord::Rollback</tt> exception, which will trigger
2008-10-05 17:16:26 -04:00
# a ROLLBACK when raised, but not be re-raised by the transaction block.
#
2010-05-01 18:40:31 -04:00
# *Warning*: one should not catch <tt>ActiveRecord::StatementInvalid</tt> exceptions
# inside a transaction block. <tt>ActiveRecord::StatementInvalid</tt> exceptions indicate that an
2008-10-05 17:16:26 -04:00
# error occurred at the database level, for example when a unique constraint
# is violated. On some database systems, such as PostgreSQL, database errors
2010-05-01 18:40:31 -04:00
# inside a transaction cause the entire transaction to become unusable
2008-10-05 17:16:26 -04:00
# until it's restarted from the beginning. Here is an example which
# demonstrates the problem:
#
# # Suppose that we have a Number model with a unique column called 'i'.
# Number.transaction do
2012-11-10 10:16:21 -05:00
# Number.create(i: 0)
2008-10-05 17:16:26 -04:00
# begin
# # This will raise a unique constraint error...
2012-11-10 10:16:21 -05:00
# Number.create(i: 0)
2008-10-05 17:16:26 -04:00
# rescue ActiveRecord::StatementInvalid
# # ...which we ignore.
# end
2009-06-02 15:42:22 -04:00
#
2008-10-05 17:16:26 -04:00
# # On PostgreSQL, the transaction is now unusable. The following
# # statement will cause a PostgreSQL error, even though the unique
# # constraint is no longer violated:
2012-11-10 10:16:21 -05:00
# Number.create(i: 1)
2008-10-05 17:16:26 -04:00
# # => "PGError: ERROR: current transaction is aborted, commands
# # ignored until end of transaction block"
# end
#
2010-05-01 18:40:31 -04:00
# One should restart the entire transaction if an
# <tt>ActiveRecord::StatementInvalid</tt> occurred.
2008-10-09 10:24:15 -04:00
#
# == Nested transactions
#
2010-05-01 18:40:31 -04:00
# +transaction+ calls can be nested. By default, this makes all database
2008-10-09 10:24:15 -04:00
# statements in the nested transaction block become part of the parent
2010-12-10 18:52:33 -05:00
# transaction. For example, the following behavior may be surprising:
2008-10-09 10:24:15 -04:00
#
# User.transaction do
2012-11-10 10:16:21 -05:00
# User.create(username: 'Kotori')
2008-10-09 10:24:15 -04:00
# User.transaction do
2012-11-10 10:16:21 -05:00
# User.create(username: 'Nemu')
2008-10-09 10:24:15 -04:00
# raise ActiveRecord::Rollback
# end
# end
2009-06-02 15:42:22 -04:00
#
2010-12-10 18:52:33 -05:00
# creates both "Kotori" and "Nemu". Reason is the <tt>ActiveRecord::Rollback</tt>
# exception in the nested block does not issue a ROLLBACK. Since these exceptions
# are captured in transaction blocks, the parent block does not see it and the
# real transaction is committed.
2008-10-09 10:24:15 -04:00
#
2010-12-10 18:52:33 -05:00
# In order to get a ROLLBACK for the nested transaction you may ask for a real
2012-11-10 10:16:21 -05:00
# sub-transaction by passing <tt>requires_new: true</tt>. If anything goes wrong,
2010-12-10 18:52:33 -05:00
# the database rolls back to the beginning of the sub-transaction without rolling
# back the parent transaction. If we add it to the previous example:
2008-10-09 10:24:15 -04:00
#
# User.transaction do
2012-11-10 10:16:21 -05:00
# User.create(username: 'Kotori')
# User.transaction(requires_new: true) do
# User.create(username: 'Nemu')
2008-10-09 10:24:15 -04:00
# raise ActiveRecord::Rollback
# end
# end
2009-06-02 15:42:22 -04:00
#
2013-03-11 21:07:17 -04:00
# only "Kotori" is created. This works on MySQL and PostgreSQL. SQLite3 version >= '3.6.8' also supports it.
2008-10-09 10:24:15 -04:00
#
# Most databases don't support true nested transactions. At the time of
# writing, the only database that we're aware of that supports true nested
# transactions, is MS-SQL. Because of this, Active Record emulates nested
2010-12-10 18:52:33 -05:00
# transactions by using savepoints on MySQL and PostgreSQL. See
2015-05-20 03:23:01 -04:00
# http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
2008-10-09 10:24:15 -04:00
# for more information about savepoints.
#
2010-06-08 16:59:06 -04:00
# === Callbacks
#
# There are two types of callbacks associated with committing and rolling back transactions:
# +after_commit+ and +after_rollback+.
#
# +after_commit+ callbacks are called on every record saved or destroyed within a
# transaction immediately after the transaction is committed. +after_rollback+ callbacks
# are called on every record saved or destroyed within a transaction immediately after the
# transaction or savepoint is rolled back.
#
# These callbacks are useful for interacting with other systems since you will be guaranteed
# that the callback is only executed when the database is in a permanent state. For example,
# +after_commit+ is a good spot to put in a hook to clearing a cache since clearing it from
# within a transaction could trigger the cache to be regenerated before the database is updated.
#
2008-10-09 10:24:15 -04:00
# === Caveats
#
# If you're on MySQL, then do not use DDL operations in nested transactions
# blocks that are emulated with savepoints. That is, do not execute statements
# like 'CREATE TABLE' inside such blocks. This is because MySQL automatically
2010-04-30 15:30:28 -04:00
# releases all savepoints upon executing a DDL operation. When +transaction+
2008-10-09 10:24:15 -04:00
# is finished and tries to release the savepoint it created earlier, a
# database error will occur because the savepoint has already been
# automatically released. The following example demonstrates the problem:
2009-06-02 15:42:22 -04:00
#
2009-01-10 16:36:09 -05:00
# Model.connection.transaction do # BEGIN
2015-05-12 08:18:55 -04:00
# Model.connection.transaction(requires_new: true) do # CREATE SAVEPOINT active_record_1
2009-01-10 16:36:09 -05:00
# Model.connection.create_table(...) # active_record_1 now automatically released
2015-05-12 08:20:42 -04:00
# end # RELEASE SAVEPOINT active_record_1
2009-01-10 16:36:09 -05:00
# # ^^^^ BOOM! database error!
2008-10-09 10:24:15 -04:00
# end
2009-04-04 12:33:36 -04:00
#
# Note that "TRUNCATE" is also a MySQL DDL statement!
2004-12-30 09:51:04 -05:00
module ClassMethods
2015-07-20 04:11:24 -04:00
# See the ConnectionAdapters::DatabaseStatements#transaction API docs.
2008-08-31 05:09:16 -04:00
def transaction ( options = { } , & block )
2009-01-10 16:36:09 -05:00
connection . transaction ( options , & block )
2004-11-23 20:04:44 -05:00
end
2010-06-08 15:41:42 -04:00
2015-02-13 21:10:53 -05:00
def before_commit ( * args , & block ) # :nodoc:
set_options_for_callbacks! ( args )
set_callback ( :before_commit , :before , * args , & block )
end
2012-08-30 00:57:41 -04:00
# This callback is called after a record has been created, updated, or destroyed.
#
# You can specify that the callback should only be fired by a certain action with
# the +:on+ option:
#
2012-11-10 10:16:21 -05:00
# after_commit :do_foo, on: :create
# after_commit :do_bar, on: :update
# after_commit :do_baz, on: :destroy
2012-08-30 00:57:41 -04:00
#
2013-10-25 16:59:48 -04:00
# after_commit :do_foo_bar, on: [:create, :update]
# after_commit :do_bar_baz, on: [:update, :destroy]
2012-08-30 00:57:41 -04:00
#
2010-06-08 15:41:42 -04:00
def after_commit ( * args , & block )
2012-12-25 13:35:52 -05:00
set_options_for_callbacks! ( args )
2010-06-08 15:41:42 -04:00
set_callback ( :commit , :after , * args , & block )
end
2012-08-30 00:57:41 -04:00
# This callback is called after a create, update, or destroy are rolled back.
#
# Please check the documentation of +after_commit+ for options.
2010-06-08 15:41:42 -04:00
def after_rollback ( * args , & block )
2012-12-25 13:35:52 -05:00
set_options_for_callbacks! ( args )
set_callback ( :rollback , :after , * args , & block )
2015-01-04 09:23:57 -05:00
end
2015-02-13 21:10:53 -05:00
def before_commit_without_transaction_enrollment ( * args , & block ) # :nodoc:
set_options_for_callbacks! ( args )
set_callback ( :before_commit_without_transaction_enrollment , :before , * args , & block )
end
2015-02-12 23:06:44 -05:00
def after_commit_without_transaction_enrollment ( * args , & block ) # :nodoc:
set_options_for_callbacks! ( args )
set_callback ( :commit_without_transaction_enrollment , :after , * args , & block )
end
def after_rollback_without_transaction_enrollment ( * args , & block ) # :nodoc:
set_options_for_callbacks! ( args )
set_callback ( :rollback_without_transaction_enrollment , :after , * args , & block )
end
2015-01-04 09:23:57 -05:00
def raise_in_transactional_callbacks
ActiveSupport :: Deprecation . warn ( 'ActiveRecord::Base.raise_in_transactional_callbacks is deprecated and will be removed without replacement.' )
true
end
def raise_in_transactional_callbacks = ( value )
ActiveSupport :: Deprecation . warn ( 'ActiveRecord::Base.raise_in_transactional_callbacks= is deprecated, has no effect and will be removed without replacement.' )
value
2012-12-25 13:35:52 -05:00
end
private
def set_options_for_callbacks! ( args )
2010-06-08 15:41:42 -04:00
options = args . last
if options . is_a? ( Hash ) && options [ :on ]
2013-06-20 14:34:41 -04:00
fire_on = Array ( options [ :on ] )
2014-01-15 18:06:53 -05:00
assert_valid_transaction_action ( fire_on )
options [ :if ] = Array ( options [ :if ] )
2013-02-21 08:54:17 -05:00
options [ :if ] << " transaction_include_any_action?( #{ fire_on } ) "
2010-06-08 15:41:42 -04:00
end
2012-12-25 13:35:52 -05:00
end
2013-02-21 08:54:17 -05:00
def assert_valid_transaction_action ( actions )
if ( actions - ACTIONS ) . any?
2014-12-07 22:13:17 -05:00
raise ArgumentError , " :on conditions for after_commit and after_rollback callbacks have to be one of #{ ACTIONS } "
2012-12-25 13:35:52 -05:00
end
2010-06-08 15:41:42 -04:00
end
2004-11-23 20:04:44 -05:00
end
2008-10-05 17:16:26 -04:00
# See ActiveRecord::Transactions::ClassMethods for detailed documentation.
2010-10-15 00:27:40 -04:00
def transaction ( options = { } , & block )
self . class . transaction ( options , & block )
2004-11-23 20:04:44 -05:00
end
2010-05-08 19:06:05 -04:00
def destroy #:nodoc:
with_transaction_returning_status { super }
2004-11-23 20:04:44 -05:00
end
2006-10-10 15:34:25 -04:00
2010-05-08 19:06:05 -04:00
def save ( * ) #:nodoc:
rollback_active_record_state! do
with_transaction_returning_status { super }
end
2004-11-23 20:04:44 -05:00
end
2006-10-10 15:34:25 -04:00
2010-05-08 19:06:05 -04:00
def save! ( * ) #:nodoc:
with_transaction_returning_status { super }
2007-01-02 00:36:30 -05:00
end
2007-01-12 00:10:06 -05:00
2013-08-26 13:15:37 -04:00
def touch ( * ) #:nodoc:
with_transaction_returning_status { super }
end
2010-11-28 10:55:48 -05:00
# Reset id and @new_record if the transaction rolls back.
2007-01-12 00:10:06 -05:00
def rollback_active_record_state!
2010-06-08 16:59:06 -04:00
remember_transaction_record_state
2007-01-12 00:10:06 -05:00
yield
rescue Exception
2010-06-08 16:59:06 -04:00
restore_transaction_record_state
raise
ensure
clear_transaction_record_state
end
2015-02-13 21:10:53 -05:00
def before_committed! # :nodoc:
Revert "Revert "Reduce allocations when running AR callbacks.""
This reverts commit bdc1d329d4eea823d07cf010064bd19c07099ff3.
Before:
Calculating -------------------------------------
22.000 i/100ms
-------------------------------------------------
229.700 (± 0.4%) i/s - 1.166k
Total Allocated Object: 9939
After:
Calculating -------------------------------------
24.000 i/100ms
-------------------------------------------------
246.443 (± 0.8%) i/s - 1.248k
Total Allocated Object: 7939
```
begin
require 'bundler/inline'
rescue LoadError => e
$stderr.puts 'Bundler version 1.10 or later is required. Please update your Bundler'
raise e
end
gemfile(true) do
source 'https://rubygems.org'
# gem 'rails', github: 'rails/rails', ref: 'bdc1d329d4eea823d07cf010064bd19c07099ff3'
gem 'rails', github: 'rails/rails', ref: 'd2876141d08341ec67cf6a11a073d1acfb920de7'
gem 'arel', github: 'rails/arel'
gem 'sqlite3'
gem 'benchmark-ips'
end
require 'active_record'
require 'benchmark/ips'
ActiveRecord::Base.establish_connection('sqlite3::memory:')
ActiveRecord::Migration.verbose = false
ActiveRecord::Schema.define do
create_table :users, force: true do |t|
t.string :name, :email
t.boolean :admin
t.timestamps null: false
end
end
class User < ActiveRecord::Base
default_scope { where(admin: true) }
end
admin = true
1000.times do
attributes = {
name: "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
email: "foobar@email.com",
admin: admin
}
User.create!(attributes)
admin = !admin
end
GC.disable
Benchmark.ips(5, 3) do |x|
x.report { User.all.to_a }
end
key =
if RUBY_VERSION < '2.2'
:total_allocated_object
else
:total_allocated_objects
end
before = GC.stat[key]
User.all.to_a
after = GC.stat[key]
puts "Total Allocated Object: #{after - before}"
```
2015-07-15 10:00:36 -04:00
_run_before_commit_without_transaction_enrollment_callbacks
_run_before_commit_callbacks
2015-02-13 21:10:53 -05:00
end
2013-06-20 14:34:41 -04:00
# Call the +after_commit+ callbacks.
2013-02-13 15:27:06 -05:00
#
# Ensure that it is not called if the object was never persisted (failed create),
2013-06-20 14:34:41 -04:00
# but call it after the commit of a destroyed object.
2015-01-09 15:35:27 -05:00
def committed! ( should_run_callbacks : true ) #:nodoc:
2015-02-12 23:06:44 -05:00
if should_run_callbacks && destroyed? || persisted?
Revert "Revert "Reduce allocations when running AR callbacks.""
This reverts commit bdc1d329d4eea823d07cf010064bd19c07099ff3.
Before:
Calculating -------------------------------------
22.000 i/100ms
-------------------------------------------------
229.700 (± 0.4%) i/s - 1.166k
Total Allocated Object: 9939
After:
Calculating -------------------------------------
24.000 i/100ms
-------------------------------------------------
246.443 (± 0.8%) i/s - 1.248k
Total Allocated Object: 7939
```
begin
require 'bundler/inline'
rescue LoadError => e
$stderr.puts 'Bundler version 1.10 or later is required. Please update your Bundler'
raise e
end
gemfile(true) do
source 'https://rubygems.org'
# gem 'rails', github: 'rails/rails', ref: 'bdc1d329d4eea823d07cf010064bd19c07099ff3'
gem 'rails', github: 'rails/rails', ref: 'd2876141d08341ec67cf6a11a073d1acfb920de7'
gem 'arel', github: 'rails/arel'
gem 'sqlite3'
gem 'benchmark-ips'
end
require 'active_record'
require 'benchmark/ips'
ActiveRecord::Base.establish_connection('sqlite3::memory:')
ActiveRecord::Migration.verbose = false
ActiveRecord::Schema.define do
create_table :users, force: true do |t|
t.string :name, :email
t.boolean :admin
t.timestamps null: false
end
end
class User < ActiveRecord::Base
default_scope { where(admin: true) }
end
admin = true
1000.times do
attributes = {
name: "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
email: "foobar@email.com",
admin: admin
}
User.create!(attributes)
admin = !admin
end
GC.disable
Benchmark.ips(5, 3) do |x|
x.report { User.all.to_a }
end
key =
if RUBY_VERSION < '2.2'
:total_allocated_object
else
:total_allocated_objects
end
before = GC.stat[key]
User.all.to_a
after = GC.stat[key]
puts "Total Allocated Object: #{after - before}"
```
2015-07-15 10:00:36 -04:00
_run_commit_without_transaction_enrollment_callbacks
_run_commit_callbacks
2015-02-12 23:06:44 -05:00
end
2010-06-08 16:59:06 -04:00
ensure
2014-05-16 14:03:40 -04:00
force_clear_transaction_record_state
2010-06-08 16:59:06 -04:00
end
2013-06-20 14:34:41 -04:00
# Call the +after_rollback+ callbacks. The +force_restore_state+ argument indicates if the record
2010-06-08 16:59:06 -04:00
# state should be rolled back to the beginning or just to the last savepoint.
2015-01-09 15:35:27 -05:00
def rolledback! ( force_restore_state : false , should_run_callbacks : true ) #:nodoc:
2015-02-12 23:06:44 -05:00
if should_run_callbacks
Revert "Revert "Reduce allocations when running AR callbacks.""
This reverts commit bdc1d329d4eea823d07cf010064bd19c07099ff3.
Before:
Calculating -------------------------------------
22.000 i/100ms
-------------------------------------------------
229.700 (± 0.4%) i/s - 1.166k
Total Allocated Object: 9939
After:
Calculating -------------------------------------
24.000 i/100ms
-------------------------------------------------
246.443 (± 0.8%) i/s - 1.248k
Total Allocated Object: 7939
```
begin
require 'bundler/inline'
rescue LoadError => e
$stderr.puts 'Bundler version 1.10 or later is required. Please update your Bundler'
raise e
end
gemfile(true) do
source 'https://rubygems.org'
# gem 'rails', github: 'rails/rails', ref: 'bdc1d329d4eea823d07cf010064bd19c07099ff3'
gem 'rails', github: 'rails/rails', ref: 'd2876141d08341ec67cf6a11a073d1acfb920de7'
gem 'arel', github: 'rails/arel'
gem 'sqlite3'
gem 'benchmark-ips'
end
require 'active_record'
require 'benchmark/ips'
ActiveRecord::Base.establish_connection('sqlite3::memory:')
ActiveRecord::Migration.verbose = false
ActiveRecord::Schema.define do
create_table :users, force: true do |t|
t.string :name, :email
t.boolean :admin
t.timestamps null: false
end
end
class User < ActiveRecord::Base
default_scope { where(admin: true) }
end
admin = true
1000.times do
attributes = {
name: "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
email: "foobar@email.com",
admin: admin
}
User.create!(attributes)
admin = !admin
end
GC.disable
Benchmark.ips(5, 3) do |x|
x.report { User.all.to_a }
end
key =
if RUBY_VERSION < '2.2'
:total_allocated_object
else
:total_allocated_objects
end
before = GC.stat[key]
User.all.to_a
after = GC.stat[key]
puts "Total Allocated Object: #{after - before}"
```
2015-07-15 10:00:36 -04:00
_run_rollback_callbacks
_run_rollback_without_transaction_enrollment_callbacks
2015-02-12 23:06:44 -05:00
end
2010-06-08 16:59:06 -04:00
ensure
restore_transaction_record_state ( force_restore_state )
2013-07-08 05:31:07 -04:00
clear_transaction_record_state
2010-06-08 16:59:06 -04:00
end
2013-06-20 14:34:41 -04:00
# Add the record to the current transaction so that the +after_rollback+ and +after_commit+ callbacks
2010-06-08 16:59:06 -04:00
# can be called.
def add_to_transaction
2015-02-01 16:52:50 -05:00
if has_transactional_callbacks?
self . class . connection . add_transaction_record ( self )
else
2015-03-04 07:24:03 -05:00
sync_with_transaction_state
2015-03-02 14:55:18 -05:00
set_transaction_state ( self . class . connection . transaction_state )
2015-02-01 16:52:50 -05:00
end
2015-02-01 16:42:53 -05:00
remember_transaction_record_state
2006-10-10 15:34:25 -04:00
end
2008-08-23 20:51:45 -04:00
# Executes +method+ within a transaction and captures its return value as a
# status flag. If the status is true the transaction is committed, otherwise
# a ROLLBACK is issued. In any case the status flag is returned.
2008-10-05 17:16:26 -04:00
#
# This method is available within the context of an ActiveRecord::Base
# instance.
2010-05-08 19:06:05 -04:00
def with_transaction_returning_status
2008-08-23 20:51:45 -04:00
status = nil
2008-12-10 15:57:19 -05:00
self . class . transaction do
2010-06-08 16:59:06 -04:00
add_to_transaction
2012-03-21 04:34:32 -04:00
begin
status = yield
rescue ActiveRecord :: Rollback
2014-05-15 15:38:05 -04:00
clear_transaction_record_state
2012-03-21 04:34:32 -04:00
status = nil
end
2012-08-18 22:04:10 -04:00
2008-08-23 20:51:45 -04:00
raise ActiveRecord :: Rollback unless status
end
status
2015-07-19 22:00:36 -04:00
ensure
if @transaction_state && @transaction_state . committed?
clear_transaction_record_state
end
2008-08-23 20:51:45 -04:00
end
2010-06-08 16:59:06 -04:00
protected
# Save the new record state and id of a record so it can be restored later if a transaction fails.
2011-12-08 14:45:54 -05:00
def remember_transaction_record_state #:nodoc:
2014-06-07 12:23:25 -04:00
@_start_transaction_state [ :id ] = id
2014-12-25 15:33:47 -05:00
@_start_transaction_state . reverse_merge! (
new_record : @new_record ,
2014-12-26 15:11:18 -05:00
destroyed : @destroyed ,
frozen? : frozen? ,
2014-12-25 15:33:47 -05:00
)
Revert "create a transaction object and point AR objects at that object 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
2012-09-14 11:44:35 -04:00
@_start_transaction_state [ :level ] = ( @_start_transaction_state [ :level ] || 0 ) + 1
2010-06-08 16:59:06 -04:00
end
# Clear the new record state and id of a record.
2014-05-16 14:03:40 -04:00
def clear_transaction_record_state #:nodoc:
Revert "create a transaction object and point AR objects at that object 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
2012-09-14 11:44:35 -04:00
@_start_transaction_state [ :level ] = ( @_start_transaction_state [ :level ] || 0 ) - 1
2014-05-16 14:20:01 -04:00
force_clear_transaction_record_state if @_start_transaction_state [ :level ] < 1
2014-05-16 14:03:40 -04:00
end
2014-05-17 04:57:16 -04:00
# Force to clear the transaction record state.
2014-05-16 14:03:40 -04:00
def force_clear_transaction_record_state #:nodoc:
@_start_transaction_state . clear
2010-06-08 16:59:06 -04:00
end
# Restore the new record state and id of a record that was previously saved by a call to save_record_state.
2011-12-08 14:45:54 -05:00
def restore_transaction_record_state ( force = false ) #:nodoc:
2012-08-20 18:08:35 -04:00
unless @_start_transaction_state . empty?
2013-07-08 05:31:07 -04:00
transaction_level = ( @_start_transaction_state [ :level ] || 0 ) - 1
if transaction_level < 1 || force
2012-08-20 18:08:35 -04:00
restore_state = @_start_transaction_state
2014-12-25 15:46:49 -05:00
thaw
2011-01-17 19:42:34 -05:00
@new_record = restore_state [ :new_record ]
@destroyed = restore_state [ :destroyed ]
2015-02-01 17:20:36 -05:00
pk = self . class . primary_key
if pk && read_attribute ( pk ) != restore_state [ :id ]
write_attribute ( pk , restore_state [ :id ] )
end
2014-12-25 15:46:49 -05:00
freeze if restore_state [ :frozen? ]
2010-06-08 16:59:06 -04:00
end
end
end
# Determine if a record was created or destroyed in a transaction. State should be one of :new_record or :destroyed.
2011-12-08 14:45:54 -05:00
def transaction_record_state ( state ) #:nodoc:
2012-08-20 18:08:35 -04:00
@_start_transaction_state [ state ]
2010-06-08 16:59:06 -04:00
end
2010-06-08 15:41:42 -04:00
# Determine if a transaction included an action for :create, :update, or :destroy. Used in filtering callbacks.
2013-02-21 08:54:17 -05:00
def transaction_include_any_action? ( actions ) #:nodoc:
actions . any? do | action |
case action
when :create
transaction_record_state ( :new_record )
when :destroy
destroyed?
when :update
! ( transaction_record_state ( :new_record ) || destroyed? )
end
2010-06-08 15:41:42 -04:00
end
end
2015-03-01 22:57:14 -05:00
2015-03-02 11:06:19 -05:00
private
2015-03-02 14:55:18 -05:00
def set_transaction_state ( state ) # :nodoc:
@transaction_state = state
2015-03-01 22:57:14 -05:00
end
def has_transactional_callbacks? # :nodoc:
! _rollback_callbacks . empty? || ! _commit_callbacks . empty? || ! _before_commit_callbacks . empty?
end
# Updates the attributes on this particular ActiveRecord object so that
2015-03-10 08:43:07 -04:00
# if it's associated with a transaction, then the state of the ActiveRecord
# object will be updated to reflect the current state of the transaction
2015-03-01 22:57:14 -05:00
#
# The @transaction_state variable stores the states of the associated
# transaction. This relies on the fact that a transaction can only be in
# one rollback or commit (otherwise a list of states would be required)
2015-03-10 08:43:07 -04:00
# Each ActiveRecord object inside of a transaction carries that transaction's
2015-03-01 22:57:14 -05:00
# TransactionState.
#
# This method checks to see if the ActiveRecord object's state reflects
# the TransactionState, and rolls back or commits the ActiveRecord object
# as appropriate.
#
# Since ActiveRecord objects can be inside multiple transactions, this
# method recursively goes through the parent of the TransactionState and
# checks if the ActiveRecord object reflects the state of the object.
def sync_with_transaction_state
2015-03-02 14:55:18 -05:00
update_attributes_from_transaction_state ( @transaction_state )
2015-03-01 22:57:14 -05:00
end
2015-03-02 14:55:18 -05:00
def update_attributes_from_transaction_state ( transaction_state )
if transaction_state && transaction_state . finalized?
restore_transaction_record_state if transaction_state . rolledback?
2015-03-02 10:40:11 -05:00
clear_transaction_record_state
2015-03-01 22:57:14 -05:00
end
end
2004-11-23 20:04:44 -05:00
end
2005-02-07 09:15:53 -05:00
end