Transactions

When working with applications that interact with databases, there are often scenarios where the business logic dictates that a particular database operation should only execute if another completes successfully. Object-Relational Mapping (ORM) tools, such as GORM, offer mechanisms to handle these situations gracefully.

In this topic, you'll delve into using GORM to initiate and manage transactions and how to avoid common transactional pitfalls to ensure optimal outcomes.

Understanding transactions in GORM

Even if you're familiar with transactions in the broader context of relational databases, they take on an additional dimension with GORM because you're juggling between Go model structs and database tables.

Think of a scenario where you're working with the library database and need to create a Book record, and then associate that new Book record with an existing Author record. It's essential that all of these operations either succeed together or fail together to maintain data consistency; this is where transactions come into play.

The primary objective of a transaction is to safeguard data integrity. If all operations within the transaction succeed, the changes are committed to the database. However, if any operation fails, all changes are reversed, ensuring the Go application's state remains aligned with the database state.

Apart from the above points, bundling operations within a transaction also optimizes performance, allowing multiple operations to share a single database connection, thus reducing the ORM overhead; this is especially beneficial considering that each operation in GORM involves generating SQL, initiating connections, and potential data transformations.

Transaction flow

Initiating transactions: You can start a new transaction via the tx := db.Begin() syntax in GORM; the db.Begin() method returns a new *DB instance that encapsulates the transactional context.

It's common to name the transaction instance tx for clear code readability. You can execute CRUD operations using this transaction instance, such as tx.Create() or tx.Delete() within the transaction's context.

Managing errors and rollbacks: As you might know, it's common for errors to occur when working with CRUD operations; ensuring data integrity is crucial, whether it's due to a data type mismatch, constraint violations, or database connectivity issues. In such scenarios, you wouldn't want partial changes to be saved.

To handle these situations, GORM provides the tx.Rollback() method. Whenever an error happens in a transaction, calling this method will revert all changes made, ensuring the database remains intact.

Committing transactions: If no errors occur during the transaction and all the operations succeed, the final step is to make the changes permanent in the database using the tx.Commit() method.

When you invoke the tx.Commit() method, you signal that all operations within the transaction succeeded, and it saves all changes to the database. This approach ensures each operation within the transaction executes as part of a single unit.

Working with transactions

Now let's further explain how to start and commit a transaction by revisiting the scenario of creating a new Book record and associating it with an existing Author record.

func main() {
    // ... Connect to the `library` sqlite3 database

    // Initiate a transaction via `db.Begin()`:
    tx := db.Begin()

    // Retrieve an existing `Publisher` with `name="Doubleday"`:
    var publisher Publisher
    result := tx.Where("name = ?", "Doubleday").First(&publisher)
    if result.Error != nil {
        log.Printf("cannot retrieve Publisher: %v\n", result.Error)
        tx.Rollback()
        return
    }

    // Declare and assign values to the new `Book` record:
    book := Book{
        Title:         "The Stand",
        DatePublished: time.Date(1978, 10, 3, 0, 0, 0, 0, time.UTC),
        PublisherID:   publisher.ID,
    }

    // Retrieve an existing `Author` with `name="Stephen King"`:
    var author Author
    result = tx.Where("name = ?", "Stephen King").First(&author)
    if result.Error != nil {
        log.Printf("cannot retrieve Author: %v\n", result.Error)
        tx.Rollback()
        return
    }

    // Set up GORM's association mode between the `authors` and `books` tables
    // And chain Append() to create a new record in the `books` and `author_books` join table:
    err = tx.Model(&author).Association("Books").Append(&book)
    if err != nil {
        log.Printf("cannot create Book and/or author_books record (or both): %v\n", err)
        tx.Rollback()
        return
    }

    // If no errors occurred, use `tx.Commit()` to commit the transaction:
    tx.Commit()

    fmt.Printf("Created Book with ID: %d, Title: %s,\nDatePublished: %s, PublisherID: %d\n",
        book.ID, book.Title, book.DatePublished, book.PublisherID)
    fmt.Printf("Created author_books record with Author ID: %d, Book ID: %d\n",
        author.ID, book.ID)
}

// Output:
// Created Book with ID: 41, Title: The Stand,
// DatePublished: 1978-10-03 00:00:00 +0000 UTC, PublisherID: 4
// Created author_books record with Author ID: 3, Book ID: 41

In the above example, the first step is to create a transaction instance tx using the Begin() method. After that, various CRUD operations get executed using the tx instance, ensuring they all run within the context of the initiated transaction:

• The first operation is retrieving an existing Publisher record and then declaring a new Book and assigning values to its fields since every Book record is tied to a PublisherID.
• The second operation is retrieving an existing Author record.
• The third operation associates the previously declared Book with the retrieved Author, creating a new Book record and a corresponding entry in the author_books join table.

Since the above actions involve distinct database operations, potential errors like a DB disconnection or a constraint violation between these steps could lead to data inconsistencies; this highlights the pivotal role transactions play in database interactions.

In the event of an error during these operations, the tx.Rollback() method is triggered, and the transaction gets immediately rolled back, ensuring that the database remains consistent despite errors. Finally, the transaction is committed to the database using the tx.Commit() method if all operations were successful and error-free.

In short, using a transaction allows you to perform the above sequence of operations as a single unit, ensuring that the database remains consistent.

Common pitfalls in using transactions

Deadlocks due to order of operations: In scenarios with concurrent database operations, maintaining a uniform order of operations across transactions is crucial. For example, if you're working with records in both the publishers and books tables concurrently, given the one-to-many relationship between them, always process the publishers table first, followed by the books table; this uniformity in operations order ensures that transactions don't wait indefinitely for each other, preventing potential deadlocks in the library database.

Strategic transactions for reads: Transactions come with overhead. While they're crucial for write operations, their necessity can vary for read operations. For instance, imagine you're working with concurrent operations on the library database; in this case, wrapping reads in transactions ensures that if another concurrent process deletes a Publisher or Author record, the operation fails gracefully, preventing potential data inconsistencies. However, avoiding unnecessary transactions for reads is advisable if you're not dealing with concurrent operations or don't need a coherent data snapshot.

Uncommitted transactions: A common oversight is to forget to commit or roll back a transaction; this leaves the changes in limbo, and they won't be reflected in the database. Always ensure that every transaction is either committed or rolled back.

Long-running transactions: Long transactions can lock resources for extended periods, causing other operations to wait and potentially leading to contention or deadlocks. Instead, aim to keep your transactions short and sweet. For instance, if you need to read a very large number of records, gather all the necessary data before initiating a transaction rather than fetching data mid-transaction.

Overly broad transaction scope: While transactions ensure atomicity, they should be used judiciously. Each transaction should have a clear, singular purpose. Avoid wrapping unrelated operations into one transaction simply because they occur close together in time.

Conclusion

In this topic, you learned how to perform transactions using GORM and that transactions can help ensure data consistency in your applications, treating a sequence of operations as a single unit that can be committed if successful or rolled back if there are any errors.

You also learned about common pitfalls with transactions and how to avoid them. Now, it's time to put this knowledge to the test with a few theory and coding tasks. Let's go!