Holding transactions as long as a user edits

As an application developer I'm used to using databases transactions only as a way to play in modifications after a user has clicked "save". That's the way most database servers I'm familiar with expect their transactions to be used and they don't like long-lived transactions. Under many circumstances, they lead to locking out other writers or even readers with very little help to deal with such blocks. But I'm only familiar with a slice of the database world - I use mostly SQL Server and have seen some MySQL. Those databases are mostly used as an application storage with business logic in the database itself mostly being reduced to generating unique ids in one way or another. I could imagine that other servers, such as Oracle, have different expectations. The approach I'm interested in is that where when the user clicks "edit", a transaction is opened and all edits the user makes are immediately send to the database. All business logic is therefore applied immediately and as such visible in the user interface even before the "save" (a.k.a. the "commit"). This paradigm would make several things easier: - The application doing the edit doesn't have to manage preliminary ids for unsaved rows as ORMs do. - The user could get feedback from business logic in the database server, such as values of computed columns or the resulting effects of triggers, even before they commit to the changes. - Constraint violations could be detected earlier in the edit if a lot of changes are made before the commit. - If the database server has good support for it, conflicting editing from multiple transactions could lead to better error messages such as "user abc is editing row xyz". [I've investigated the state of SQL Server support for this approach](https://dba.stackexchange.com/questions/318050/the-finer-points-of-writers-locking-each-other-out-under-the-snapshot-isolation) and it's something on the verge of being possible but probably usually a bad idea in practice. The main issue is that writers there lock each other out even under snapshot isolation. In particular, the writer who writes first wins, not the one who commits first. My question is: Are there database servers that support this scenario better? What does Oracle have to say to this, for example? In particular, the server would have to - Allow concurrent writes to the same row without blocking and having the first committer win. - Therefore, an uncommitted, dangling transaction that has written should not affect other users at all. If a different user commits a conflicting write that should work, and the dangling transaction just becomes uncommittable (or is just automatically rolled back at that point). I'm looking into this for my [generic database browser](https://squil.azurewebsites.net) ;