2017-02-05 2 views
1

Предположим, у меня есть два потока, которые должны выполнять атомарные операции Read-Mofify-Write в базе данных SQLite (в Android).Android: можно ли исключать исключения из базы данных SQLite во время транзакций?

Для того, чтобы обеспечить атомарность, я оборачивать логику транзакций базы данных:

try { 
    database.beginTransaction(); 
    ... read-modify-write logic here 
    database.setTransactionSuccessful(); 
} 
finally { 
    database.endTransaction(); 
} 

Эта сделка является ЭКСКЛЮЗИВ по умолчанию (по крайней мере на Android). Производительность (пропускная способность) не является фактором (клиентская сторона - не так много ожидаемых транзакций).

До сих пор все хорошо, но один вопрос беспокоит меня: в то время как вышеописанный шаблон try-finally обеспечит согласованность базы данных в случае возникшего исключения, если действительно произойдет исключение, и я его не поймаю - мое приложение будет crash ...

Когда речь заходит о моем собственном коде, я знаю, какие исключения могут быть брошены и как их обрабатывать, но я попытался понять, какие исключения могут быть выбраны самой базой данных SQLite в этом случае (если есть) но я не могу найти его документированным в любом месте.

Итак, мои вопросы относительно к вышеприведенному коду:

  1. Какой фатальным исключение может быть сгенерированы, когда один поток выполняет этот код (со смертельным исходом = безвозвратным, пусть сбой приложения)?
  2. Какие нефатальные исключения могут быть выбрасываться, когда один поток выполняет этот код и как я могу их обработать?
  3. Если один поток уже в транзакции и другой поток пытается начать новую транзакцию, будет ли второй поток блокироваться до тех пор, пока первый не завершится или не будет выбрано исключение?

Заранее спасибо

ответ

2

Во время операций с базами данных, все виды нарушений ограничений может произойти, но те, как правило, указывают на ошибку программирования. Кроме того, чтение или запись файла базы данных может приводить к любой случайной аппаратной ошибке, которая может привести к произвольному исключению.

И, наконец, если база данных заблокирована слишком долго, вы получаете исключение «база данных заблокировано». Вы можете настроить время ожидания для определенного соединения с помощью PRAGMA busy_timeout (значение по умолчанию не полезно).

+0

О, мой, я должен был подумать о нарушениях ограничений сам ... Можете ли вы также помочь мне уточнить «тяжести»? 1) Мое решение, является ли нарушение ограничений фатальным или восстанавливаемым, не так ли? 2) Ошибки аппаратного обеспечения, о которых вы упоминаете, вероятно, можно считать редкими фатальными ошибками и игнорировать (т. Е. Сбой приложения), правильно? 3) Если я правильно понял, исключение «блокировка базы данных» будет выбрано для ожидающего потока, если он ждет слишком долго, верно? Я бы сказал, что это указывает на ошибку реализации и может рассматриваться как фатальный (мое приложение не является критичной системой)? Thanks – Vasiliy

+0

Вы не можете обрабатывать ошибки, которые не знаете. «Слишком долго» зависит. –

+0

Понял. спасибо – Vasiliy

Смежные вопросы