In order to know what happens during a commit or a rollback, we need to know what kind of state changes occur during a transaction.
When we try to store an object, a page is allocated for the object. The object may not fit into one page and may exceed the page size which is called an overflow. Whenever there is an overflow, an additional page is allocated to accommodate the extra bytes. Thus a storage operation may involve one or more page updates.
Each page update is cached within the transaction till the transaction is either committed or roll-backed.
In the below diagram, we have a bunch of pages where page 0 accommodates an object which spans more than one page(0-3-5-7). Page 0 has a next attribute which points to the next page 3 which contains the remaining data. Page 3 again points to page 5 which in turn points to page 7. Page 7 is of type ‘End’ as the object data ends here, the other pages are of type ‘Part’ as they contain only part of data.
When we free a page, the data the page is holding is nullified and the page type in the header is updated to ‘Free’ so that the page can be re-used. All the pages involved to store the object also get freed.
In the above case, when we free page 0, page 3, 5 and 7 also get freed. The freed pages are added to the free list. Whenever we free a page, it results into a page update as the data is eliminated and header is changed. The updated pages must be written back to the file when we issue commit. The free list created during a transaction must be merged with the PageFile’s free list.
If the total size of page updates within a transaction exceeds the allowed size, the data is written to a temporary file owned by the transaction. This file is open in ‘read/write’ mode till we are done with the transaction.
Each transaction has an ID assigned. Work occurred during the transaction may result into page updates, a temporary file, freed pages and pages allocated.