| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a `before_commit` callback raises, the database is rolled back but
AR's record of the current transaction is not, leaving the connection in
a perpetually broken state that affects all future users of the
connection: subsequent requests, jobs, etc. They'll think a transaction
is active when none is, so they won't BEGIN on their own. This manifests
as missing `after_commit` callbacks and broken ROLLBACKs.
This happens because `before_commit` callbacks fire before the current
transaction is popped from the stack, but the exception-handling path
they hit assumes that the current transaction was already popped. So the
database ROLLBACK is issued, but the transaction stack is left intact.
Common cause: deadlocked `#touch`, which is now implemented with
`before_commit` callbacks.
What's next:
* We shouldn't allow active transaction state when checking in or out
from the connection pool. Verify that conns are clean.
* Closer review of txn manager sad paths. Are we missing other spots
where we'd end up with incorrect txn state? What's the worst that can
happen if txn state drifts? How can we guarantee it doesn't and
contain the fallout if it does?
Thanks for @tomafro for expert diagnosis!
|
|
|
|
| |
Fixes https://github.com/rails/rails/issues/22819
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 393e65b4170608593ad82377a9eadc918e85698d and
ec51c3fedd16b561d096dcc1a6705fdc02ab7666
We don't want the records to hold hard references to transactions
because they point at records that have callbacks.
|
|
|
|
|
| |
this lets us keep singleton instances of "state" values and precalculate
return values of things like `finalized?` and `completed?`.
|
|
|
|
|
| |
this way we don't have to mutate a state object, we can just change the
state of the txn
|
| |
|
|
|
|
| |
As far as I can tell nobody is setting this variable.
|
|
|
|
| |
[fixes #18903]
|
| |
|
|
|
|
|
| |
the transaction object shouldn't know so much about active record
objects, so let's push the conditionals in to the instance.
|
| |
|
| |
|
|
|
|
|
|
| |
after_commit callbacks run after committing a transaction whose parent
is not `joinable?`: un-nested transactions, transactions within test
cases, and transactions in `console --sandbox`.
|
|
|
|
| |
It is up to the TransactionManager keep the state of current transaction, so after it commits it needs to copy any remaning record to the next current transaction
|
|
|
|
| |
As discussed before, those methods should receive a keyword args instead of just parameters
|
|
|
|
|
|
|
|
| |
Before this change any error raised inside a transaction callback
are rescued and printed in the logs.
Now these errors are not rescue anymore and just bubble up,
as the other callbacks.
|
|\
| |
| |
| | |
Data corruption risk: Roll back open transactions when the running thread is killed.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, Active Record will rescue any errors raised within
after_rollback/after_create callbacks and print them to the
logs. Next versions of rails will not rescue those errors anymore,
and just bubble them up, as the other callbacks.
This adds a opt-in flag to enable that behaviour, of not rescuing
the errors.
Example:
# For not swallow errors in after_commit/after_rollback
config.active_record.errors_in_transactional_callbacks = true
[fixes #13460]
|
|
|
|
|
|
|
|
|
| |
after_commit should not run in nested transactions, however they should
run once the outermost transaction gets committed. This patch fixes the
problem copying the records from the Savepoint to its parent. So the
RealTransaction will have all records that needs to run callbacks on it.
[fixes #16425]
|
|
|
|
|
|
| |
Use `commit_transaction`/`rollback_transaction` on
`within_new_transaction` method, so they make sure they `pop` the
transaction from the stack before calling the methods `commit`/`rollback`.
|
|
|
|
|
|
|
|
|
| |
Transaction class doesnt need to encapsulate the transaction state using
inheritance.
This removes all Transaction subclasses, and let the Transaction object
controls different actions based on its own state. Basically the only
actions would behave differently are `being`,`commit`,`rollback` as they
could act in a savepoint or in a real transaction.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This piece of code was introduced on
67d8bb963d5d51fc644d6b1ca20164efb4cee6d7 , which was calling
`committed?` in the `transaction_state` before calling the `committed!`
method. However on 7386ffc781fca07a0c656db49fdb54678caef809, the
`committed?` check was removed and replaced by a `finalized?`, which
only checks if the state is not nil. Thus we can remove that line.
|
| |
|
|
|
|
| |
Also add test to assets the savepoint name
|
|
|
|
|
|
|
| |
Add a transaction manager per connection, so it can controls the
connection responsibilities.
Delegate transaction methods to transaction_manager
|
|
|
|
|
|
|
|
|
|
| |
The finishing variable on the transaction object was a work-around for
the savepoint name, so after a rollback/commit the savepoint could be
released with the previous name.
related:
9296e6939bcc786149a07dac334267c4035b623a
60c88e64e26682a954f7c8cd6669d409ffffcc8b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression (#13744) that was caused by 67d8bb9.
In 67d8bb9, we introduced lazy rollback for records, such that the
record's internal states and attributes are not restored immediately
after a transaction rollback, but deferred until they are first
accessed.
This optimization is only performed when the model does not have any
transactional callbacks (e.g. `after_commit` and `after_create`).
Unfortunately, the models used to test the affected codepaths all
comes with some sort of transactional callbacks. Therefore this
codepath remains largely untested until now and as a result there are
a few issues in the implementation that remains hidden until now.
First, the `sync_with_transaction_state` (or more accurately,
`update_attributes_from_transaction_state`) would perform the
synchronization prematurely before a transaction is finalized (i.e.
comitted or rolled back). As a result, when the actuall rollback
happens, the record will incorrectly assumes that its internal states
match the transaction state, and neglect to perform the restore.
Second, `update_attributes_from_transaction_state` calls `committed!`
in some cases. This in turns checks for the `destroyed?` state which
also requires synchronization with the transaction stae, which causes
an infnite recurrsion.
This fix works by deferring the synchronization until the transaction
has been finalized (addressing the first point), and also unrolled
the `committed!` and `rolledback!` logic in-place (addressing the
second point).
It should be noted that the primary purpose of the `committed!` and
`rolledback!` methods are to trigger the relevant transactional
callbacks. Since this code path is only entered when there are no
transactional callbacks on the model, this shouldn't be necessary. By
unrolling the method calls, the intention here (to restore the states
when necessary) becomes more clear.
|
| |
|
|
|
|
| |
with new transaction state. If AR object has a callback, the callback will be performed immediately (non-lazily) so the transaction still has to keep records with callbacks.
|
|
|
|
| |
new transaction state object upon initialization.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If your database supports setting the isolation level for a transaction,
you can set it like so:
Post.transaction(isolation: :serializable) do
# ...
end
Valid isolation levels are:
* `:read_uncommitted`
* `:read_committed`
* `:repeatable_read`
* `:serializable`
You should consult the documentation for your database to understand the
semantics of these different levels:
* http://www.postgresql.org/docs/9.1/static/transaction-iso.html
* https://dev.mysql.com/doc/refman/5.0/en/set-transaction.html
An `ActiveRecord::TransactionIsolationError` will be raised if:
* The adapter does not support setting the isolation level
* You are joining an existing open transaction
* You are creating a nested (savepoint) transaction
The mysql, mysql2 and postgresql adapters support setting the
transaction isolation level. However, support is disabled for mysql
versions below 5, because they are affected by a bug
(http://bugs.mysql.com/bug.php?id=39170) which means the isolation level
gets persisted outside the transaction.
|
|
|
|
| |
Accidentally checked in commented test code. Fail. >_<
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|