Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Hm, let's list all cases. </p> <p><code>REQUIRES_NEW</code> does not truely nest transactions, but as you mentioned pauses the current one. There are then simply two transactions accessing the same information. (This is similarly to two regular concurrent transactions, except that they are not concurrent but in the same thread of execution). </p> <pre><code>T1 T2 T1 T2 ― ― | | | ― | ― | | | | = | | ― | ― | | | ― ― </code></pre> <p>Then we need to consider <strong>optimistic</strong> vs. <strong>pessimistic</strong> locking.</p> <p>Also, we need to consider <strong>flushes</strong> operated by ORMs. With ORMs, we do not have a clear control when writes occurs, since <code>flush</code> is controlled by the framework. Usually, one implicit flush happens before the commit, but if many entries are modified, the framework can do intermediate flushes as well. </p> <p>1) Let's consider optimistic locking, where read do not acquire locks, but write acquire exclusive locks. </p> <p>The read by T1 does not acquire a lock. </p> <p>1a) If T1 did flush the changes prematurly, it acquired a exclusive lock though. When T2 commits, it attempts to acquire the lock but can't. <strong>The system is blocked.</strong> This can be though of a particular kind of deadlock. Completion depends on how transactions or locks time out. </p> <p>1b) If T1 did not flush the changes prematurly, no lock has been acquired. When T2 commits, it acquires and releases it and is sucessful. When T1 attempt to commit, it notices a conflict and fails. </p> <p>2) Let's consider pessimistic locking, where read acquire shared locks and write exclusive locks. </p> <p>The read by T1 acquire a shared lock. </p> <p>2a) If T1 flushed prematurly, it turnes the lock inta an exclusive lock. The situation is <strong>similar as 1a)</strong></p> <p>2b) If T1 did not flush prematurly, T1 holds a shared lock. When T2 commits, it attempts to acquire an exclusive lock and blocks. <strong>The system is blocked again</strong>. </p> <p>Conclusion: it's fine with optimistic locking if no premature flushes happen, which you can not stricly control. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload