是否yieldIfContendedSafely()失去了交易的好处是什么? [英] Does yieldIfContendedSafely() lose the benefits of a transaction?

查看:300
本文介绍了是否yieldIfContendedSafely()失去了交易的好处是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有我在后台线程中执行长时间运行的操作。由于这是为手术重要的不是成功完成或根本没有,我在包裹交易整个操作。

用户界面的各方面需要只读在此期间对数据库的访问。为了避免阻塞UI,我与插入调用 db.yieldIfContendedSafely()在后台运行的主循环试验。

这做什么,我想,该UI不再受阻,但如果这是冒着数据完整性的丧失它不是完全清楚我的。

yieldIfContendedSafely()的javadoc中说:


  

暂时结束交易,让其他线程运行。该
  交易被认为是成功为止。不要打电话
  调用此之前setTransactionSuccessful。当这个返回一个新的
  交易将被创建,但没有标记为成功。本
  假定没有嵌套事务(调用BeginTransaction
  只有被调用一次),并会抛出一个异常,如果这是不是
  案例。


这是否意味着我的长期运行的操作实际上是被提交到数据库中的单独的块,或者说是的的事务保持足够的状态在最后提交一大堆一气呵成,因此,preserving数据的完整性?


解决方案

  

这是否意味着我的长期运行的操作实际上是被承诺在单独的块数据库


是的。在 yieldIfContendedSafely(),Android把 setTransactionSuccessful() endTransaction(),并开始一个新的事务 - 在提交过程中的语句。没有机制它结束后,回滚真正的交易。

仅当有另一个线程等待数据库,否则 yieldIfContendedSafely()不做任何事发生此行为。

我有以下情形选中此。我开始两个线程:一种插入数据到表使用事务,另一个读取数据了同桌。本次交易不叫 setTransactionSuccessful()因此通常都被回滚到了最后,离开餐桌空。我加入到呼叫 yieldIfContendedSafely(),事后该表不为空,并从交易数据了。

I have a long-running operation which I perform in a background thread. As it is important for the operation to either complete successfully or not at all, I am wrapping the entire operation in a transaction.

Aspects of the UI need read-only access to the database during this time. To avoid blocking the UI, I am experimenting with inserting calls to db.yieldIfContendedSafely() in the main loop of the background operation.

This does what I want in that the UI is no longer blocked, but it's not completely clear to me if this is risking a loss of data integrity.

The javadoc for yieldIfContendedSafely() says:

Temporarily end the transaction to let other threads run. The transaction is assumed to be successful so far. Do not call setTransactionSuccessful before calling this. When this returns a new transaction will have been created but not marked as successful. This assumes that there are no nested transactions (beginTransaction has only been called once) and will throw an exception if that is not the case.

Does this mean that my long-running operation is actually being committed to the database in separate chunks, or is the overall transaction maintaining enough state to commit the whole lot in one go at the end, thus preserving data-integrity?

解决方案

Does this mean that my long-running operation is actually being committed to the database in separate chunks

Yes. Within yieldIfContendedSafely(), Android calls setTransactionSuccessful(), endTransaction(), and begins a new transaction -- committing your statements in the process. There is no mechanism to rollback the "real" transaction after it ends.

This behavior only occurs if there is another thread waiting on the database, otherwise yieldIfContendedSafely() does nothing.

I checked this with the following scenario. I started two threads: one inserted data into a table using a transaction, another read data out of the same table. The transaction didn't call setTransactionSuccessful() so normally everything is rolled back at the end, leaving the table empty. I added a call to yieldIfContendedSafely(), and afterwards the table was not empty and had data from the transaction.

这篇关于是否yieldIfContendedSafely()失去了交易的好处是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆