understanding prepare conflict

[Tristan Su]

hi,

Trying to understand prepare-conflict in 2pc transactions.  The doc says:

Reads between the prepare timestamp and commit timestamp of a
transaction that has been prepared but not committed fail with

::WT_PREPARE_CONFLICT. 

and 

The WT_SESSION::prepare_transaction method assigns a prepare timestamp to the
transaction, which will be used for visibility checks until the transaction is
committed or aborted.  

1. does that mean writes in a prepared(but not yet committed) txn are visible globally?

2. why ignoring-prepare will break repeatable read?

 

I'm new to WT and must be missing something here, any help is appreciated.

Regards,

Tristan 

[Chenhao Qu]

Hi Tristan,

1. No, it is not globally visible and it is also not visible. That’s why a prepared conflict error is returned in this case. WiredTiger visibility is determined by two mechanisms: WiredTiger txn id and timestamps. For a txn that is prepared but not committed, it is visible in terms of WiredTiger txn id and potentially visible in terms of timestamps. To prevent it from being visible to the user, we return the prepared conflict error in this case.

2. Ignore prepared config means it will read past any prepared conflict WiredTiger encounters. For example, if we have a prepared update and a committed update for a key, we will read the committed update in the first read because of the ignore prepared config. Then if we commit the prepared update, the next read of the key in the same transaction may read the prepared update, thus breaking the repeated read promise.

Hope this answers your question.

Cheers,

Chenhao

--
You received this message because you are subscribed to the Google Groups "wiredtiger-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wiredtiger-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wiredtiger-users/92756fb8-485f-451a-b22f-57cf22594a33n%40googlegroups.com.

[Tristan Su]

Hi Chenhao,

I've got the point,  after reading the Clock-SI paper (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/samehe-clocksi.srds2013.pdf).

Basically I was missing the point that a prepared transaction may be assigned a commit-ts less than the current read-ts, in a distributed cluster.  I made the misassumption that the commit-ts should be larger than the current read-ts.

Thanks！

Tristan