Question about "Transactions in context values"

[MarioCarrion]

This is copy/paste of a thread on Twitter regarding the video I created covering the "queries pattern" (aka Transaction Script):

Source: https://twitter.com/DevSomto/status/1829019268870004766

It took me a minute to grasp this concept, but I got a question to solidify my understanding. Since context.Context lives throughout the lifecycle of a request, and assuming the custom transaction function is used within every method in the repository layers,

if an error occurs during the execution of the function passed to transaction, the transaction is rolled back. This rollback operation affects the entire transaction, which includes all operations performed before the error was encountered. In other words

if an error occurs at any point within the function, all prior operations that were part of that transaction are rolled back. The context itself facilitates this by ensuring that the transaction's lifecycle is correctly managed throughout the request?

mind you I just took of my question from YouTube as I realized you have twitter haha

[codescratchers]

Hi @MarioCarrion ,

Thank you for responding to my question. My question in the tweet was aimed at clarifying my understanding of the video. If I'm correct, you're using context.Context to determine when to commit or rollback a transaction since it persists throughout the request lifecycle, right?

[codescratchers]

Take for example similar to your video/blog post, I defined refactored you dbTransaction to tailor to using mysql. Because the context.Context is injected all the way from the request handler, and every query in the repository layer are defined withing DbTransaction if for some reason during the request lifecycle an error occurs, a database rollback is occurs.

func DbTransaction(ctx context.Context, tx *sql.Tx, f func(context.Context) error) error {
	if err := f(ctx); err != nil {
		if err := tx.Rollback(); err != nil {
			return fmt.Errorf("db rollback %w", err)
		}
		return fmt.Errorf("f %w", err)
	}

	if err := tx.Commit(); err != nil {
		return fmt.Errorf("db commit %w", err)
	}

	return nil
}

[codescratchers]

I'll spit out a sample example of something similar to the project I am currently working on to gain more experience with Golang and better understand Enterprise Application Architecture pattern in your blog

[MarioCarrion]

Thanks for the context @codescratchers.

Now that you mentioned it, I should have used an HTTP handler to demonstrate what I meant because that's where this is typically useful.

In the video, I recommend the opposite: not using context to include the transaction but rather refactoring the underlying code that happens to need a transaction to use another type (the "transaction script") to drive this logic, to reuse existing repositories that can support transactions if required.

See UserCloner.Clone, this method drives the transaction not the layers above it (like an HTTP handler). If you see the code for the used types (example User) you will notice they refer to the DBTX type so in practice the repository types could work with a standard connection type or a transaction type.

The goal of the blog/video is to show a way to define boundaries between users of the repositories and the repositories themselves; this means the upper layers do not start a transaction, but rather repositories handle that while reusing existing repositories as well.

I hope this helps.

Cheers.

[codescratchers]

Yes, I understood the second suggestion as well, but implementing it with a standard HTTP handler and MySQL was quite tricky for me, especially since I've only recently started learning Go. My main challenge with the second approach was having access to handling *sql.Tx in DBTX type, so I reverted to the first suggestion. Incase I am not clear you can check out a rough example of my implementation trying to grasp your blog repo.

I hope this clarifies my situation.

Cheers.