0

我在共享文件夹上有一个 SQLite3 数据库。我想从 Java 应用程序覆盖 db 文件。尽管此文件的读写流量较低，但我想确保 a) 覆盖不会损坏 db 文件，并且 b) 任何可能希望访问 db 文件的人基本上会看到它被锁定，直到覆盖完成了。我目前的计划看起来像这样......

String query = "BEGIN EXCLUSIVE TRANSACTION";
/* Execute this query*/
File sourceFile = new File(LocalPath);
File destFile = new File(DbPath);

InputStream inStream = new FileInputStream(sourceFile);
OutputStream outStream = new FileOutputStream(destFile);

byte[] buffer = new byte[1024];

int length;

while((length = inStream.read(buffer)) > 0) {
    outStream.write(buffer, 0, length);
}

inStream.close();
outStream.close();

/* Now release lock */

query = "ROLLBACK TRANSACTION";

/* Execute query */

所以在这里阅读 SQLite 的指导http://www.sqlite.org/howtocorrupt.html，看起来这个锁会存在于日志中，并在我运行回滚事务时在复制后更新。同时，如果客户端在我复制时尝试访问 Db，我想他们只是找不到该文件，而我的 SQLite 驱动程序假定该 db 不存在。对？

我的问题是......在数据库上加锁是否有争议？有没有更好的策略或方法让数据库看起来被锁定而不是丢失？另外，我是否在数据库损坏中冒着巨大的风险，这使得这不可行？我的另一个想法是锁定 db 文件，将新文件写入不同的名称，然后在写入完成后重命名，然后释放锁......对此有什么想法吗？

不确定覆盖数据库文件是否是一个绝妙的主意，但对于我拥有的资源，我能想到的唯一可行的事情（通过网络在共享文件夹中的数据库上运行大量事务的速度慢得令人无法接受。我知道我在共享文件夹上使用 SQLite 数据库时存在更高的损坏风险）。我正在本地编写更新，然后让用户选择“提交”更改并启动 db 文件复制。

除了回答我的问题外，欢迎对这个案例提出任何一般性建议......

4

1 回答 1

1

备份 API允许您覆盖数据库。

（我不知道你的 Java 包装器是否公开了这个 API。）

于 2012-09-12T16:11:07.607 回答