Comment 5 for bug 600032

Hi!

I disagree on this approach. The transaction services layer has, up to this point, followed the principle of not passing *anything* over to the replication stream if a COMMIT did not occur -- the ONLY exception to this was for bulk operations. A RollbackStatement message should be written to the replication stream if and only if:

a) a ROLLBACK SQL statement is executed, AND
b) a bulk operation has already sent a Transaction message into the replication stream

In other words, if an applier receives a RollbackStatement message in a Transaction on its end it can safely assume it may ignore any received Statement messages in that transaction and drop them all.

I would recommend keeping this approach for two reasons:

1) Don't assume an applier knows anything about savepoints. Remember that appliers can also be NoSQL stores. A Rollback should mean "discard anything you've received so far about this transaction"
2) KISS

I would do the following:

In TransactionServices::setSavepoint(), do a std::copy() of existing Transaction message to a saved location. The easiest way to do so would be to modify the drizzled::NamedSavepoint class to contain a member of type pointer to message::Transaction.

In TransactionServices::releaseSavepoint(), remember to clean up the memory allocated in the copy above for the copied Transaction message

In TransactionServices::rollbackToSavepoint(), simply discard the Session's existing Transaction message and set the pointer to the NamedSavepoint's copy of the Transaction message at savepoint time.

Don't send anything over the replication stream in the event of a ROLLBACK TO SAVEPOINT. Just copy/modify the Transaction message for that Session. This will keep the replication stream simple and straightforward, which is A Good Thing.

Cheers!
jay