On Thu, Sep 11, 2014 at 12:49 PM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:

Robert Hodges <robert.hodges@continuent.com> writes:

> What would be cool is something like a group transaction that other threads
> can join so that the commit becomes atomic. Most of the parallel load use
> cases I can think of don't require you to coordinate things like isolation
> because they are conflict free anyway--it's just atomic group commit.

Hm, I don't quite have this.

Given T1 and T2, there is a facility to ensure that T2 will commit no sooner
than T1. But there is no facility to prevent T1 from commiting before T2.

(This is what was needed for parallel replication).

In that case it gets complex for outsiders to figure out how to restart if there's a failure. Let's say my transaction fails after T1 commits but before T1 commits. Then on restart I have to regenerate T2 and rerun it. That could be hard if T2 contains statements that came before T1 in the original, serialized log.

Without a "group" transaction another approach is to keep separate restart points for each worker thread. It works well as long as you can deterministically assign transactions to threads and keep those same threads from getting too far apart. The logic to do this is non-trivial, so it's not an approach for everybody.

Cheers, Robert

- Kristian.