Hi Kristian, 

That's an intriguing proposal.  There are numerous applications involving tasks like restoring backups in parallel where being able to ensure all or nothing commit across a group of client threads would be incredibly handy. To my knowledge no other RDBMS offers it.  It's also a great feature for data warehouse loading.  We usually have to fake it on Tungsten by tricks to make transactions idempotent.  These work poorly in conventional RDBMS due to constraint checking. 

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. 

I had a quick look in Weikum and Vossen (2002).  If you have that handy there are several interesting discussions about parallel transactions. It sounds as if you have something similar baked in and just need to expose it. (But you probably read W&V closely already before writing any code. :)

Cheers, Robert

On Thu, Sep 11, 2014 at 12:17 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Robert Hodges <robert.hodges@continuent.com> writes:

> Thanks Kristian. That's a nice optimization that is difficult to do outside
> the DBMS engine.

Indeed. We might be able to expose it to you, though. Like SET SESSION
wait_for_other_commit=<processid>, or something.

 - Kristian.