Reter transações enquanto um usuário editar

Como desenvolvedor de aplicativos, estou acostumado a usar transações de banco de dados apenas como forma de jogar nas modificações depois que um usuário clica em "salvar".

É assim que a maioria dos servidores de banco de dados com os quais estou familiarizado espera que suas transações sejam usadas e não gostam de transações de longa duração. Sob muitas circunstâncias, eles levam ao bloqueio de outros escritores ou mesmo leitores com muito pouca ajuda para lidar com esses bloqueios.

Mas estou familiarizado apenas com uma fatia do mundo do banco de dados - uso principalmente o SQL Server e já vi alguns MySQL. Esses bancos de dados são usados ​​principalmente como armazenamento de aplicativos com lógica de negócios no próprio banco de dados sendo reduzido principalmente para gerar IDs exclusivos de uma forma ou de outra.

Eu poderia imaginar que outros servidores, como o Oracle, tenham expectativas diferentes.

A abordagem que me interessa é aquela em que quando o usuário clica em "editar", uma transação é aberta e todas as edições que o usuário faz são enviadas imediatamente para o banco de dados. Toda a lógica de negócios é, portanto, aplicada imediatamente e, como tal, visível na interface do usuário, mesmo antes do "salvar" (também conhecido como "commit").

Esse paradigma facilitaria várias coisas:

• O aplicativo que faz a edição não precisa gerenciar ids preliminares para linhas não salvas, como fazem os ORMs.
• O usuário pode obter feedback da lógica de negócios no servidor de banco de dados, como valores de colunas computadas ou os efeitos resultantes de gatilhos, mesmo antes de se comprometer com as alterações.
• Violações de restrição podem ser detectadas mais cedo na edição se muitas alterações forem feitas antes do commit.
• Se o servidor de banco de dados tiver um bom suporte para ele, a edição conflitante de várias transações pode levar a mensagens de erro melhores, como "usuário abc está editando a linha xyz".

Eu investiguei o estado do suporte do SQL Server para essa abordagem e é algo prestes a ser possível, mas provavelmente geralmente uma má ideia na prática. O principal problema é que os escritores de lá bloqueiam uns aos outros mesmo sob isolamento de instantâneo. Em particular, o escritor que escreve primeiro ganha, não aquele que se compromete primeiro.

Minha pergunta é: Existem servidores de banco de dados que suportam melhor esse cenário? O que a Oracle tem a dizer sobre isso, por exemplo? Em particular, o servidor teria que

• Permitir gravações simultâneas na mesma linha sem bloquear e fazer o primeiro committer vencer.
• Portanto, uma transação não confirmada e pendente que foi gravada não deve afetar outros usuários. Se um usuário diferente confirmar uma gravação conflitante que deve funcionar, e a transação pendente se tornar não confirmável (ou será revertida automaticamente nesse ponto).

Estou procurando isso para o meu navegador de banco de dados genérico ;