Чи повинен я здійснити або відмовити прочитану транзакцію?

У мене є запит на читання, який я виконую в рамках транзакції, щоб я міг вказати рівень ізоляції. Що робити після завершення запиту, що мені робити?

• Здійснити транзакцію
• Відкат транзакції
• Нічого не робити (що призведе до відкочування транзакції в кінці використовуваного блоку)

Які наслідки має виконання кожного з них?

using (IDbConnection connection = ConnectionFactory.CreateConnection())
{
    using (IDbTransaction transaction = connection.BeginTransaction(IsolationLevel.ReadUncommitted))
    {
        using (IDbCommand command = connection.CreateCommand())
        {
            command.Transaction = transaction;
            command.CommandText = "SELECT * FROM SomeTable";
            using (IDataReader reader = command.ExecuteReader())
            {
                // Read the results
            }
        }

        // To commit, or not to commit?
    }
}

EDIT: Питання не в тому, чи слід використовувати транзакцію, чи існують інші способи встановити рівень транзакції. Питання полягає в тому, чи має значення різниця в тому, що транзакція, яка нічого не змінює, є скоєною або відкатаною. Чи є різниця в продуктивності? Чи впливає це на інші зв’язки? Будь-які інші відмінності?

Ти робиш. Період. Іншої розумної альтернативи немає. Якщо ви розпочали транзакцію, вам слід закрити її. Фіксація звільняє будь-які замки, які ви мали, і це однаково розумно з рівнями ізоляції ReadUncommitted або Serializable. Надія на неявний відкат - хоча, можливо, технічно еквівалентна - це просто погана форма.

Якщо це вас не переконало, просто уявіть наступного хлопця, який вставляє оператор оновлення в середину вашого коду і повинен відстежувати неявний відкат, який відбувається, і видаляє його дані.

Якщо ви нічого не змінили, тоді ви можете використати COMMIT або ROLLBACK. Будь-який із них випустить усі отримані вами блокування читання, і оскільки ви не вносили жодних інших змін, вони будуть рівнозначними.

Якщо ви починаєте транзакцію, найкращою практикою є завжди її вчинення. Якщо всередині вашого блоку використання (транзакції) буде внесено виняток, транзакція буде автоматично відкатана.

IMHO може мати сенс обертати запити лише на читання в транзакціях, оскільки (особливо на Java) ви можете сказати, що транзакція має статус "лише для читання", що, у свою чергу, драйвер JDBC може розглянути можливість оптимізації запиту (але не обов'язково, тому ніхто заважатиме вам видавати INSERTвсе ж). Наприклад, драйвер Oracle повністю уникне блокування таблиць для запитів у транзакції, позначеній лише для читання, що значно покращує продуктивність програм, що сильно керуються читанням.

Розглянемо вкладені транзакції .

Більшість СУБД не підтримують вкладені транзакції або намагаються наслідувати їх дуже обмежено.

Наприклад, в MS SQL Server, відкат у внутрішній операції (яка не є реальною транзакцією, MS SQL Server тільки підраховує рівні транзакцій!) Буде відкотити все , що сталося в самому далекому від центру угоди (яка є реальною угодою).

Деякі обгортки баз даних можуть розглядати відкат у внутрішній транзакції як ознаку того, що сталася помилка, і відкотити все в самій транзакції, незалежно від того, здійснено чи відкотчено крайню транзакцію.

Отже, COMMIT - це безпечний спосіб, коли ви не можете виключити, що ваш компонент використовується якимось програмним модулем.

Зверніть увагу, що це загальна відповідь на запитання. Приклад коду розумно вирішує проблему із зовнішньою транзакцією, відкриваючи нове підключення до бази даних.

Щодо продуктивності: залежно від рівня ізоляції, SELECTS можуть вимагати різного ступеня БЛОКУВАННЯ та тимчасові дані (знімки). Це очищається, коли транзакція закрита. Не має значення, чи це робиться за допомогою COMMIT чи ROLLBACK. Може бути незначна різниця у витраченому часу процесора - COMMIT, швидше за все, швидше аналізується, ніж ROLLBACK (на два символи менше) та інші незначні відмінності. Очевидно, що це справедливо лише для операцій лише для читання!

Повністю не просять: інший програміст, який може прочитати код, може припустити, що ROLLBACK означає стан помилки.

Просто допоміжна примітка, але ви також можете написати цей код так:

using (IDbConnection connection = ConnectionFactory.CreateConnection())
using (IDbTransaction transaction = connection.BeginTransaction(IsolationLevel.ReadUncommitted))
using (IDbCommand command = connection.CreateCommand())
{
    command.Transaction = transaction;
    command.CommandText = "SELECT * FROM SomeTable";
    using (IDataReader reader = command.ExecuteReader())
    {
        // Do something useful
    }
    // To commit, or not to commit?
}

І якщо ви трохи реструктуруєте речі, можливо, ви зможете також перемістити використовуючий блок для IDataReader вгору.

Якщо ви помістите SQL у збережену процедуру і додасте це над запитом:

set transaction isolation level read uncommitted

тоді вам не потрібно перестрибувати будь-які обручі в коді C #. Встановлення рівня ізоляції транзакції в збереженій процедурі не призводить до того, що параметр застосовується до всіх майбутніх застосувань цього підключення (це те, про що вам слід турбуватися з іншими налаштуваннями, оскільки з’єднання об’єднано). В кінці збереженої процедури вона просто повертається до того, з чим було ініціалізоване з'єднання.

ROLLBACK використовується здебільшого у разі помилки або виняткових обставин, а COMMIT - у випадку успішного завершення.

Ми повинні закривати транзакції з COMMIT (для успіху) та ROLLBACK (для помилки), навіть у випадку транзакцій лише для читання, де це, здається, не має значення. Насправді це має значення для послідовності та забезпечення майбутнього.

Транзакція лише для читання може логічно "провалитися" багатьма способами, наприклад:

• запит не повертає рівно один рядок, як очікувалося
• збережена процедура викликає виняток
• отримані дані виявляються суперечливими
• користувач перериває транзакцію, оскільки це займає занадто багато часу
• тупик або час очікування

Якщо COMMIT і ROLLBACK використовуються належним чином для транзакції лише для читання, вона буде продовжувати працювати, як очікувалося, якщо в якийсь момент буде додано код запису DB, наприклад, для кешування, аудиту або статистики.

Неявний ЗВЕРНЕННЯ слід використовувати лише в ситуаціях "фатальної помилки", коли програма аварійно завершує роботу або виходить із непоправленою помилкою, збоєм мережі, відключенням електроживлення тощо.

Враховуючи, що READ не змінює стан, я б нічого не робив. Виконання коміту нічого не призведе, крім втрати циклу надсилання запиту до бази даних. Ви не виконували операцію, яка змінила стан. Так само для відкату.

Однак слід обов’язково очистити об’єкти та закрити з’єднання з базою даних. Якщо не закрити з’єднання, це може призвести до проблем, якщо цей код буде викликатися неодноразово.

Якщо ви встановили AutoCommit false, тоді YES.

В експерименті з JDBC (драйвер Postgresql) я виявив, що якщо запит на вибір обривається (через тайм-аут), ви не можете ініціювати новий запит на вибір, якщо не виконаєте відкат.

У зразку коду, де ви маєте

1. // Зробіть щось корисне

   Ви виконуєте оператор SQL, який змінює дані?

Якщо ні, транзакція "Прочитати" не існує ... У транзакції знаходяться лише зміни з інструкцій "Вставити", "Оновити" та "Видалити" (оператори, які можуть змінювати дані) ... Про що Ви говорите, це про замки, які SQL Сервер розміщує дані, які ви читаєте, через ІНШІ транзакції, які впливають на ці дані. Рівень цих блокувань залежить від рівня ізоляції SQL Server.

Але ви не можете ні комітувати, ні повертати нічого, якщо ваш оператор SQL нічого не змінив.

Якщо ви змінюєте дані, ви можете змінити рівень ізоляції, не починаючи явно транзакцію ... Кожен окремий оператор SQL неявно є транзакцією. явно розпочати транзакцію потрібно лише для того, щоб переконатися, що 2 або більше операторів знаходяться в межах однієї транзакції.

Якщо все, що вам потрібно зробити, це встановити рівень ізоляції транзакції, тоді просто встановіть CommandText команди на "Set Transaction Isolation level Repeatable Read" (або будь-який рівень, який ви хочете), встановіть CommandType на CommandType.Text і виконайте команду. (Ви можете використовувати Command.ExecuteNonQuery ())

ПРИМІТКА. Якщо ви виконуєте МНОЖЕВІ оператори читання і хочете, щоб усі вони "бачили" такий самий стан бази даних, як і перший, тоді вам потрібно встановити рівень ізоляції зверху Повторюване читання чи серіалізація ...

Вам потрібно заблокувати іншим читання тих самих даних? Навіщо використовувати транзакцію?

@Joel - Моє запитання було б краще сформулювати так: "Навіщо використовувати транзакцію для запиту на читання?"

@Stefan - Якщо ви збираєтеся використовувати AdHoc SQL, а не збережений процес, просто додайте WITH (NOLOCK) після таблиць у запиті. Таким чином ви не несете накладні витрати (хоча і мінімальні) у програмі та базі даних для транзакції.

SELECT * FROM SomeTable WITH (NOLOCK)

EDIT @ Коментар 3: Оскільки у вас у тегах запитань був "sqlserver", я припустив, що цільовим продуктом є MSSQLServer. Тепер, коли цей момент з’ясовано, я відредагував теги, щоб видалити конкретне посилання на товар.

Я досі не впевнений у тому, чому ви спочатку хочете здійснити транзакцію за прочитаним записом.