This is quite a generalised point so difficult to really respond to but some frameworks do provide a mechanism to check if a transaction has been closed. The stateless nature of web development does also make working with transactions easier as you have a clear entry and exit point of each request. However I appreciate not all uses of RDBMSs are stateless, let alone web applications. But a similar approach can sometimes be applied with static stateful applications where you can calve up the transactional operations into logical code paths that are easier to mentally visualise. As always though, it really depends on how your code is structured and the specific problems you're trying to solve.

Where you know code boundaries are an issue I've found functional designs tend to work a little better than OOP with regards to managing transactions but a lot of that could just be down to how my brain is wired (while I'm not a FP evangelist I do tend to favour breaking code down to stateless functions rather than stateful classes).

It's fair to say spaghetti code will be a problem on most reasonably mature code bases but there are approaches and frameworks that help somewhat with managing transactions across code boundaries -- just as there are tools that make working with transactions harder. But in my experience there are much harder problems to solve than working with transactions.

> but it's not like they are a zero-overhead feature.

Is there such thing as a zero overhead feature? (I say this semi-flippantly).

I mean I have to deal with this crap at $dayjob but I genuinely can't believe of the terrible code I see that borrows a resource (connection, transaction, file handle) and then only the happy path gives it back. I desperately wish that languages would make this a compile error if all code paths don't lead to the resource being freed.

The only thing that should ever stop you from returning a resource is a malicious scheduler.

> I desperately wish that languages would make this a compile error if all code paths don't lead to the resource being freed.

You might want to take a look at rust.

I can see the obvious parallels between memory management lifetimes and transaction management, does rust have explicit features for extending lifetimes to resources besides memory?

Yes, it works for files, network connections and database transactions[1].

To span a transaction over two functions, it has to be assigned to some variable and the lifetime of this variable is tracked by the compiler.

[1] https://docs.rs/sqlx/0.3.0/sqlx/struct.Transaction.html

You don’t need to solve the halting program, you just need a way to construct programs that halt (or close the connection), which is way easier.

Many languages have some sort of `finally` or `with` construct tailored for this use case.

Remember, we’re code writers, not arbitrary discriminators.