它还具有接受任何数据库写入任务的中央阻止任务队列的服务;活动可以触发将任务放在阻塞队列上的服务请求(作为意图),以便通过单个线程执行顺序检索.数据库大约在4mb.
有一个单一的数据库帮助器,该服务用于调用方法与数据库进行交互,包括写入它;所有sql写入都在数据库帮助器中执行.
>所有数据库写入都被事务包围.
>所有数据库读取都会在方法结束时关闭游标.
>没有一个Activity具有数据库对象的句柄,它们只能通过内容提供商或服务进行通信.
>任何AlarmManager触发的任务(如活动)只能使用该服务将相应的任务弹出到队列中.
>该服务是唯一具有数据库助手句柄的类.
>所有数据库写入仅通过放在队列上的任务执行;我已经精疲力尽地检查了任务执行是否顺序地清楚,必须避免对sqlite数据库的并发写入.
在执行任务执行期间,我一直在尝试写入数据库时发现一个或两个“数据库被锁定”错误,这些错误是由任务执行“begin transaction”触发的.
在尝试跟踪锁的源时,我发现使用dbhelper.inTransaction(),dbhelper.isLockedByThisThread(),dbhelper.isLockedByOtherThread()没有帮助,因为它们不会指示意外的数据库锁定.
我发现早期检测锁定的方法是在一个try_transaction()和setTransactionSuccessful方法中创建一个没有任何实际的sql编写代码的方法,在一个可以记录问题的try catch块中 – 始终由beginTransaction()触发.
我把这个数据库锁定陷阱放在每个阻塞队列任务方法的一边,期望/希望我会发现一个奇怪的罪魁祸首,在数据库处于锁定状态.
我找不到一个罪魁祸首.在从任务调用开始到数据库写入之后,我发现数据库锁可能会出现在蓝色之外,没有被先前运行的任务锁定(所有这些任务在相同的单数线程下顺序运行).
在查看了许多其他人员遇到数据库锁定问题后,我已经在所有任务完成事务之后直接关闭数据库连接,但是如果有什么似乎可以获得更多的数据库锁定事件,那么这并没有帮助.尝试在每个任务执行之间添加一个睡眠;没有经过全面测试,但通常发现延迟3秒或以上似乎阻止数据库锁出现.试图禁用报警管理器发射任务 – 没有任何区别.
我的印象是,我的应用程序外部的某种形式的维护任务会定期丢失并锁定数据库 – 也许延迟写入日志.显然,我不太热衷于设置任务处理延迟,所以我考虑有一个数据库锁重试任务队列来重新尝试数据库写作;非常喜欢解决,但没有想法.
有没有人会想到我错过的一些原则？
在Android和大型sqlite数据库中,现实是否正常,您会偶尔获得数据库锁？
谢谢
