No. Exposing primitives like commit or “begin transaction” isn’t bad or irresponsible design; working with databases is ridiculously hard, which becomes apparent when demand increases.
Combining that with spaghetti that does transaction magic at random places guarantees the sort of pain that makes cursing the entire human race seem like a pretty mild response.
Higher-level abstractions may prevent some footguns; e.g., an “atomic” decorator/annotation commits automatically after a successful call. They are somewhat easier to understand but come with their own limitations and caveats.
This is like people saying that C is infallible and it’s those stupid lesser-developers that unlike me simply cannot wield its immense power.
No. Usability matters. After all these years software development still has an ‘unfounded male confidence / posturing’ problem and it’s just cringeworthy
I agree. No matter how complicated, or unnecessary, or unintuitive a piece of software or technology is... There is always this contingent of people who pop in and say "It is not that hard!" and furthermore tend to express a view of "I am superior because I figured out this obtuse thing, and you must be inferior because you have not figured it out".
I do not know why that mentality exists in the industry, but I see it all the time... for the past 35 years.
Database engines I've worked with generally support nested transactions, so you can open a transaction, open another transaction, commit it, then roll back the outer transaction... and it's like nothing ever happened.
This ability to compose transactions is their main benefit over other kinds of concurrency control!
For those that don't, it's almost always modeled in the connection-library as "hold it open until commits == opens, or roll back if any roll back". Or it's often easy to build this yourself, around the library.
Which works entirely fine in most cases. You're at greater risk of phantom reads and general "stuff that can occur while you hold open a transaction", but if you're not handling that correctly then you're not handling that correctly. It's only a matter of volume, not existence.
... with a clear exception for cases where you do need to truly end a transaction, like if you're relying on some other thread to do something on a different transaction that needs to see your changes, or when you risk a deadlock somewhere due to not releasing your lock. Those are both a risky patterns for a lot of reasons though, and worth avoiding at design-time if at all possible.