| >
> They will basically start a transaction issue appropriate ENQs and DEQs
> and instead of commiting will issue an Abort. They would like to get
> some feeling of whether resource demands for a commit are greater than
> an abort or vice versa.
>
As far as journal usage goes, there should not be much difference.
Whether the TX is aborted or committed, RTR still needs to keep a
record of the state of the TX, since anything can happen at any time to
any part of the configuration! If a TX was in the middle of an abort
when a backend goes down, for example, RTR has to know that the state
of this TX was abort when the backend comes back up again.
As far as other resources go (TX coordination overhead?) there probably
would not be much difference either, since an abort has to be
coordinated across all paritipants just as much as a commit does...
I suppose this means that these sort of TXs will not be replayed to a
server after a failure, so maybe there is a small saving there.
But I don't know if it makes much sense to use this technique. If the
TX is aborted, and it is spread over multiple partitions, then one
simply doesn't know whether each of the partitions actually got it's
part of the TX. The part-tx on another backend might still be queued
waiting for a server, for example. (and this does assume that the abort
if coming from the server after a vote request has been received -- if
the TX is aborted on the client, then the TX might never have got to
any server at all...)
ed
|