Lines Matching full:commit

60 commit boundaries, whilst "one shot" transactions are for a single atomic
198 that the common/fast path transaction will commit two linked transactions in a
259 sleep during the transaction commit process waiting for new log space to become
263 then wake up transaction commit in progress.
280 after the commit completes. Once the commit completes, we can sleep waiting for
334 implement long-running, multiple-commit permanent transactions. 
457 the delayed logging tracking lock to commit the transaction. However, the
467 transaction commit while the item is locked in the transaction. Instead of
475 rewriting can all be done while the object is locked during transaction commit,
560 in transaction commit order, so when an object is relogged it is removed from
595 formatted log items and a commit record at the tail. From a recovery
606 the transaction commit record, but tracking this requires us to have a
621 workloads, just like the existing transaction commit code does. This, however,
622 requires that we strictly order the commit records in the log so that
627 into the new CIL, then checkpoint transaction commit code cannot use log items
680 commit the checkpoint.
683 attached to the log buffer that the commit record was written to along with a
706 committed transactions with the log sequence number of the transaction commit.
713 To do this, transactions need to record the LSN of the commit record of the
728 Then, instead of assigning a log buffer LSN to the transaction commit LSN
729 during the commit, we can assign the current checkpoint sequence. This allows
738 checkpoint commit completes, it is removed from the committing list. Because
739 the checkpoint context records the LSN of the commit record for the checkpoint,
740 we can also wait on the log buffer that contains the commit record, thereby
762 transactions to remain untouched (i.e. commit an asynchronous transaction, then
773 amount of log space required as we add items to the commit item list, but we
818 The problem with this is that it can lead to deadlocks as we may need to commit
828 result of a transaction commit inserting a new memory buffer into the CIL, then
846 checkpoint commit to complete. This background push is checked and executed by
847 transaction commit code.
861 Currently log items are pinned during transaction commit while the items are
870 as there is a 1:1 relationship with transaction commit and log item completion.
872 For delayed logging, however, we have an asymmetric transaction commit to
874 through the commit process without a corresponding completion being registered.
875 That is, we now have a many-to-one relationship between transaction commit and
877 log items becomes unbalanced if we retain the "pin on transaction commit, unpin
884 the CIL during a transaction commit, then we do not pin it again. Because there
891 CIL commit/flush lock. If we pin the object outside this lock, we cannot
896 (or not pinning, as the case may be). Hence we must hold the CIL flush/commit
903 commits must scale to many concurrent commits. The current transaction commit
908 As a result, the delayed logging transaction commit code needs to be designed
914 	3. Checkpoint commit ordering
916 Looking at the transaction commit and CIL flushing interactions, it is clear
918 the number of concurrent transactions that can be trying to commit at once is
923 The amount of time a transaction commit needs to hold out a flush is a
929 the transaction commit side.
931 Because of the number of potential transaction commit side holders, the lock
938 transaction commit or CIL flush side sleeps with the lock held.
941 compared to transaction commit for asynchronous transaction workloads - only
943 transaction commit concurrency due to cache line bouncing of the lock on the
946 The second serialisation point is on the transaction commit side where items
949 commit/flush exclusion. It also needs to be an exclusive lock but it is only
954 The final serialisation point is the checkpoint commit record ordering code
955 that is run as part of the checkpoint commit and log force sequencing. The code
958 before writing the commit record. This loop walks the list of committing
959 checkpoints and needs to block waiting for checkpoints to complete their commit
965 events they are waiting for are different. The checkpoint commit record
966 sequencing needs to wait until checkpoint contexts contain a commit LSN
967 (obtained through completion of a commit record write) while log force
993 	6. Transaction commit
996 		Write commit LSN into transaction
1006 			Write commit LSN into log item
1038 	6. Transaction commit
1054 		sequence commit records
1063 			Write commit LSN into log item