diff options
| author | Owen Jacobson <owen.jacobson@grimoire.ca> | 2014-05-28 16:11:01 -0400 |
|---|---|---|
| committer | Owen Jacobson <owen.jacobson@grimoire.ca> | 2014-05-28 16:11:01 -0400 |
| commit | b0c376d2a7ded722cd49f88e515c53632ec75730 (patch) | |
| tree | de354549a8285063f482975bf44db7ba97f47c29 /wiki/mysql/broken-xa.md | |
| parent | 693eec80b65299ff679a458bb7039d656ece550f (diff) | |
Typographic fixes around double quotes.
Diffstat (limited to 'wiki/mysql/broken-xa.md')
| -rw-r--r-- | wiki/mysql/broken-xa.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/wiki/mysql/broken-xa.md b/wiki/mysql/broken-xa.md index ff7fa75..19afe22 100644 --- a/wiki/mysql/broken-xa.md +++ b/wiki/mysql/broken-xa.md @@ -15,8 +15,8 @@ manual](http://dev.mysql.com/doc/refman/5.5/en/xa-restrictions.html): If you're solving the kinds of problems where two-phase commit and XA transaction management look attractive, then you very likely have the kinds of -uptime requirements that make replication mandatory. "It works, but not with -replication" is effectively "it doesn't work". +uptime requirements that make replication mandatory. “It works, but not with +replication” is effectively “it doesn't work.” > It is possible that the server will roll back a pending XA transaction, even > one that has reached the PREPARED state. This happens if a client connection @@ -25,5 +25,5 @@ replication" is effectively "it doesn't work". XA transaction managers assume that if every resource successfully reaches the PREPARED state, then every resource will be able to commit the transaction -"eventually". Resources that unilaterally roll back PREPARED transactions +“eventually.” Resources that unilaterally roll back PREPARED transactions violate this assumption pretty badly. |