| Title: | Reliable Transaction Router |
| Moderator: | TALER::DESHMUKH |
| Created: | Tue Dec 12 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 695 |
| Total number of notes: | 2564 |
My customer has asked for some inidicative performance data on the
overheads of "aborting" an RTR transaction verses commiting it. In the
environment they are interested in there are no shadow and no standby
serves for these transactions. The question relates to the issue in
note 660 where the customer is exploring ways to reduce journal file
size.
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.
Any feedback welcomed
Wayne
(ESF Technical Support Sydney Australia)
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 671.1 | not much difference | DECALP::KLAVINS | Ed Klavins, RTR Engineering | Mon Feb 10 1997 07:25 | 30 |
>
> 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
| |||||
| 671.2 | Use RTR broadcasts, if you don't want journalling | FFRANC::DESHMUKH | Dipankar Deshmukh, RTR (US) Engg | Sat Feb 15 1997 00:17 | 6 |
If they don't care about the transactions and only want to preserve journal space, why not use the named broadcast feature? That way, RTR can route the request to the appropriate server(s) and there is no journalling involved. -dipu- | |||||