aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove @state.parent assignment on commitArthur Neves2014-07-291-2/+1
| | | | | | | | | 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.
* Extract the transaction class to a local variableRafael Mendonça França2014-07-281-6/+2
|
* savepoint_name should return nil for non-savepoint transactionsArthur Neves2014-07-281-1/+6
| | | | Also add test to assets the savepoint name
* Transactions refactoringArthur Neves2014-07-281-0/+58
| | | | | | | Add a transaction manager per connection, so it can controls the connection responsibilities. Delegate transaction methods to transaction_manager
* Remove finishing? method from transaction.Arthur Neves2014-07-241-23/+10
| | | | | | | | | | 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
* Restore ActiveRecord states after a rollback for models w/o callbacksGodfrey Chan2014-01-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* fix typos in AR. lots of them.Vipul A M2013-03-191-1/+1
|
* Reduced memory leak problem in transactions by lazily updating AR objects ↵wangjohn2013-02-201-3/+10
| | | | 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.
* Refactored transaction state into its own object. Each transaction creates a ↵wangjohn2013-01-211-5/+24
| | | | new transaction state object upon initialization.
* Created state for a transaction and added tests.wangjohn2013-01-201-0/+12
|
* Support for specifying transaction isolation levelJon Leighton2012-09-211-9/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix testJon Leighton2012-09-151-13/+19
| | | | Accidentally checked in commented test code. Fail. >_<
* Move transaction joinability into the transaction objectJon Leighton2012-09-151-1/+8
|
* Alter the naming structure a bitJon Leighton2012-09-151-105/+103
|
* Split Open into Real and SavepointJon Leighton2012-09-151-25/+38
|
* Don't do the rollback in #commitJon Leighton2012-09-151-17/+6
| | | | | The caller needs to have knowledge of the rollback either way, so do it all in the caller (#transaction)
* Store the transaction number in the transaction objectJon Leighton2012-09-151-5/+24
| | | | This avoids us having to manually increment and decrement it.
* Start to tease out transaction handling into a state machineJon Leighton2012-09-151-0/+124
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-01 00:24:01 +0000