Estou trabalhando em um projeto .NET bastante antigo e introduzi alguns novos recursos (no topo) que geraram o seguinte efeito colateral: todos os SELECTs gerados (ou grupos de) são agrupados em BEGIN TRAN ... COMMITinstruções.
Isso parece bobo, mas livrar-se disso requer muitas mudanças e não posso me dar ao luxo de fazê-lo. Minha suposição é que isso basicamente significa uma pequena sobrecarga para cada grupo de SELECTs (ida e volta entre o aplicativo e o SQL Server para BEGIN TRAN e COMMIT).
Eu estou querendo saber se há mais para isso (bloqueio extra?).
Pergunta: Existe algum efeito colateral se as instruções select forem encapsuladas em BEGIN TRAN ... COMMIT?
A resposta depende de qual nível de isolamento seu projeto .NET está definindo ao acessar o SQL Server.
Se for
READ COMMITTED(o padrão), então não há realmente nenhuma sobrecarga adicional (além das instruções adicionaisBEGIN TRANeEND TRANsendo executadas). Você pode pensar que informações adicionais seriam gravadas no log de transações, mas as transações realmente não "começam" até que algo aconteça que precise ser registrado. Eu escrevi sobre isso aqui: As transações não começam no BEGIN TRANSe você estiver usando o
SERIALIZABLEnível de isolamento, poderá se queimar pelo fato de que essasSELECTconsultas manterão os bloqueios que levam durante a transação. Isso pode estar acontecendo sem você perceber se estiver usandoTransactionScopeem seu projeto .NET, já que isso é usadoSERIALIZABLEpor padrão (consulte minha postagem no blog para uma demonstração: TransactionScope Considered Annoying ).Eu diria que, em suma, se o nível de isolamento padrão estiver sendo usado, não há muita desvantagem em deixar as coisas do jeito que você descreveu. Você deve ter cuidado com os níveis de isolamento.