Are long-living transactions acceptable?

Long-living transactions were a topic for hot discussion in academia around... 1980s I'd say. The problem is that a long-living transaction almost certainly creates a deadlock in a pessimistic execution and almost certainly requires complicated conflict resolution in an optimistic execution (for numbers you can consult Jim Gray's paper "The Dangers of Replication and a Solution", but shortly deadlocks rise as the fifth power of the transaction size, and the probability of a collision rises as the second power).

Now there were different proposals to the problem, like "sagas" from Salem and Garcia-Molina, "nested transactions" and so on (another Jim Gray's paper "The Transaction Concept: Virtues and Limitations" has several pages about that in the end). Most of the proposals deal with a transaction model, weaker than ACID. For example, "long transactions" may have to expose their intermediate results, which violates the Isolation property. But none of the proposals quite made it to the industry, so to say. Mostly because those techniques weren't really... simplifying, neither weren't necessary to solve the actual business problems.

So, to answer your question: no, long-living transactions are not welcome in the mainstream DB engines.

Here is a few problem that you might encounter if you go this way

• connection reset/close/timeout (if user goes to the bathroom)
• database configuration (database are mostly pre-configured for many short transactions, not long ones. E.g. the undo log that keeps track of what has been done during the tx may need to be tuned)
• lock issues, even maybe deadlocks (the longer the transactions are, bigger the chances are the same lock is acquired twice possibly in conflicting order)

This is a discouraged practice. Use optimistic locking instead. Read data when necessary, keep a copy in memory. When dialog is closed, attempt to synchronize the changes with the database. If data have been modified in the database in between, the action is aborted. The probability that it fails will depend on the numer of users, etc. But this is frequently acceptable in practice.

Long running transactions will seriously affect your ability to scale.

I would avoid if at all possible.

As others have noted, you should not keep a transaction open while waiting for user input.