Não pode funcionar assim. Considerar:

• programa um, você abre uma transação e insere em uma tabela FOO que tem uma chave primária autoinc (arbitrariamente, dizemos que ela recebe 557 por seu valor de chave).
• O programa dois inicia, ele abre uma transação e insere na tabela FOO obtendo 558.
• Programe duas inserções na tabela BAR que tem uma coluna que é uma chave estrangeira para FOO. Então agora o 558 está localizado em FOO e BAR.
• Programa dois agora confirma.
• O programa três inicia e gera um relatório da tabela FOO. O registro 558 é impresso.
• Depois disso, o programa um reverte.

Como o banco de dados recupera o valor 557? Ele entra em FOO e diminui todas as outras chaves primárias maiores que 557? Como ele corrige BAR? Como ele apaga o 558 impresso na saída do programa de relatório três?

Os números de sequência do Oracle também são independentes das transações pelo mesmo motivo.

Se você conseguir resolver esse problema em tempo constante, tenho certeza que pode ganhar muito dinheiro na área de banco de dados.

Agora, se você tiver um requisito de que seu campo de incremento automático nunca tenha lacunas (para fins de auditoria, digamos). Então você não pode reverter suas transações. Em vez disso, você precisa ter um sinalizador de status em seus registros. Na primeira inserção, o status do registro é "Incompleto" então você inicia a transação, faz seu trabalho e atualiza o status para "competir" (ou o que você precisar). Então, quando você se compromete, o registro é ao vivo. Se a transação for revertida, o registro incompleto ainda estará lá para auditoria. Isso causará muitas outras dores de cabeça, mas é uma maneira de lidar com trilhas de auditoria.