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

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

Чи вкладається наступна транзакція блокування в БД?

Приклад коду для отримання з БД:

Transaction tx = HibernateUtil.getCurrentSession().beginTransaction(); // why begin transaction?
//readonly operation here

tx.commit() // why tx.commit? I don't want to write anything

Чи можна використовувати session.close() замість tx.commit()?

Насправді у вас можуть бути причини маркувати транзакції як лише для читання.

1. Трансакції для читання можуть виглядати справді дивними, і часто люди не відзначають методів транзакцій у цьому випадку. Але JDBC все одно створить транзакції, просто це буде працювати, autocommit=trueякщо інша опція не була встановлена ​​явно.
2. Але немає гарантії, що ваш метод не запише в базу даних. Якщо ви позначите метод як @Transactional(readonly=true), Spring встановить транзакцію JDBC в режим лише для читання, таким чином, ви будете диктувати, чи можливо насправді записати в БД в межах цієї транзакції. Якщо ваша архітектура громіздка, і деякі члени команди можуть вирішити поставити запит на модифікацію там, де цього не передбачається, цей прапор вказує на проблемне місце.
3. Також БД можуть оптимізувати транзакції лише для читання, але це, звичайно, специфічно для БД. Наприклад, MySQL додав підтримку для цього лише в InnoDB, починаючи з версії 5.6.4.
4. Якщо ви не використовуєте JDBC безпосередньо, а скоріше ORM, це може бути проблематично. Наприклад, спільнота зі сплячого режиму говорить, що робота поза транзакцією може спричинити непередбачувану поведінку. Це відбувається тому, що Hibernate відкриє транзакцію, але не закриє її самостійно, таким чином з'єднання буде повернуто до пулу підключення, коли транзакція не буде здійснена. Що ж відбувається тоді? JDBC зберігає мовчання, таким чином, це специфічна для впровадження (MySQL відмовляє транзакції, Oracle afair здійснює це). Це також можна налаштувати на рівні Connection Pool (наприклад, C3P0 надає вам таку опцію, відкат за замовчуванням).
5. Інша справа, коли справа доходить до сплячого режиму, Spring встановлює FlushMode на MANUAL у випадку транзакцій лише для читання, що призводить до інших оптимізацій, таких як відсутність необхідності у брудних чеках.
6. Ви можете скасувати або чітко встановити рівень ізоляції транзакцій. Це впливає також на транзакції з читанням, оскільки ви чи не хочете читати невмілі зміни, піддаючись фантомним читанням тощо.

Підводячи підсумок - можна піти обома шляхами, але потрібно зрозуміти наслідки.

Усі висловлювання бази даних виконуються в контексті фізичної транзакції, навіть коли ми не заявляємо прямо межі транзакції (BEGIN / COMMIT / ROLLBACK).

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

Якщо оголосити послугу такою @Transactional, ви отримаєте одне з'єднання протягом усієї тривалості транзакції, і всі оператори будуть використовувати це єдине з'єднання для ізоляції. Це краще, ніж спочатку не використовувати явні транзакції.

У великих програмах у вас може бути багато одночасних запитів, і зниження швидкості запитів на отримання з'єднання з базою даних безумовно покращить вашу загальну ефективність програми.

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

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

Тепер, якщо вам пощастило, а ваші запити до БД такі, що ORM завжди відображає їх на єдині SQL запити, ви можете піти без явних транзакцій, спираючись на вбудовану поведінку автокомісії DB, але ORM - це досить складна система тому покладатися на таку поведінку зовсім не безпечно, якщо ви не займетеся набагато більшою роботою, перевіряючи, чим реально займається реалізація. Записати явні межі транзакцій набагато простіше правильно (особливо якщо ви можете це зробити за допомогою AOP або якоїсь подібної методики, керованої ORM; я думаю, що з Java 7 можна використовувати і тест-ресурси).

Неважливо, читаєте ви чи ні, база даних все ще повинна відслідковувати ваш набір результатів, оскільки інші клієнти бази даних можуть захотіти записати дані, які змінили б ваш набір результатів.

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