[quote=AllMighty]Usar 2PC em transações que envolvem processamento assíncrono não gera problemas com locking excessivo? Se demora horas ou dias entre o start e o commit de uma transação e a taxa de TPS é alta, o BD vai acabar todo trancado por causa de lock escalation. Ou tem alguma coisa óbvia que eu não estou enxergando aqui?
[/quote]
Depende muito de como esse processamento for implementado e como o banco de dados funciona.
O banco pode implementar multi versionamento e nesse caso somente locks solicitados pela transação são gerados. O ruim é que o transaction log (undo/redo logs do oracle) ficam enormes pois não podem sofrer flush enquanto ocorre uma transação ao risco dela falhar por conta de um “snapshot too old”, quando os logs sofrem flush mesmo com transações pendentes.
O banco pode usar locks explicitos, como o DB2, nesse caso o banco pode sofrer problemas de lock escalation, mas dependendo da implementação, transações paradas ou de longa duração tem seus locks armazenados em disco de maneira semelhante ao tx log. O problema maior mesmo é o excesso de deadlocks que isso constuma gerar ou lock escalation.
um processo de negócios que demore, digamos, seis meses para ser compeltado pode influenciar em milhares (literalmente) de outras transações. Não importa a tecnologia, isso nunca vai ser simples.
isso me lembra algo que li ha muito tempo e nem lembro onde sobre a dificuldade dos bancos de dados atuais em implementar transações de longo prazo, e o texto fazia um paralelo com sistemas de SCM.
Um sistema de SCM trabalha com compensação. Se você modifica um código fonte diveras vezes para implementar um detrminado caso de uso durante um mês vai gerar (num sistema grande, ao menos) um mar de dependências em outros fontes. Em termos tecnológicos é muito simples reverter o arquivo em questão no SCM, mas acertar os estragos nos fontes dependentes deste não é simples nem barato.
Obviamente seria quae que insano utilizar transações para processos invocados de maneira assíncrona, até pq o processamento assíncrono é desacoplado do chamador. O chamador pode efetivar o commit sem que necessariamente o processo assíncrono tenha sido bem sucedido.