| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 689.1 | aborted with REPLYDIFF on V2.2, but not V3 | DECALP::KLAVINS | Ed Klavins, RTR Engineering | Wed Apr 16 1997 04:08 | 25 |
| >
> 1. whether RTR compares "ENQ"ed message from failed server with
> "ENQ"ed message from currently active server, if they are
> not exactly same, RTR send ABORT_TX.
>
Depends whether this is RTR V2 or V3. The feature described above was
introduced in RTR about V2.2 timeframe, I believe, and is in all
subsequent V2 releases.
RTR V3 does not implement this feature (i.e. if the replies for a
replayed TX differ, the TX will not be aborted).
> 2. the way my customer can receive COMMIT_TX instead of ABORT_TX.
>
In RTR V2.2 and above (prior to V3), I don't think there is a way to
disable this. May have to re-evaluate the reason that the commit time
needs to be sent from server to client. It is measuring the time
elapsed between the server committing, and the client receiving the
commit. Is this a useful measure? Admittedly, this is a bit of a
construed question, since I agree, there may be times when servers may
want to send data back to the client which may differ between
invocations of the server. But I'm afraid this behaviour will have to
be taken into account when designing the application.
ed
|
| 689.2 | | DECALP::KLAVINS | Ed Klavins, RTR Engineering | Wed Apr 16 1997 04:17 | 14 |
| > disable this. May have to re-evaluate the reason that the commit time
> needs to be sent from server to client. It is measuring the time
> elapsed between the server committing, and the client receiving the
> commit. Is this a useful measure? Admittedly, this is a bit of a
Just a correction to my previous reply. To be more precise, sending the
commit time from server to client is not measuring the elapsed time
between server committing and client receiving the commit. It's sending
an indication of what the server thinks the time was when it committed
the TX. What does the client do with this time? Unless the client and
server are on the same machine, then this data isn't useful apart from
telling the user what time the server thinks it was. Or is it?
ed
|
| 689.3 | thank's & inform me V3 receiving ABORT | DEKVC::JONGHOLEE | | Fri Apr 18 1997 13:13 | 21 |
|
Hi,
I thank you for your help.
My customer will modify their application's specification according to
RTR V2 feature. And, the clients are on Win95 based computers.
Actually, the time is very important for their business requirements
of futures and option trading. Server program processes a transaction
with different manner, and it's criterion is received time of a
transaction from client. Also, client should and can know how his
transaction will be processed by time from server.
I have tested V2 source program under V3. The program received "Success"
about replayed TX message. But, my customer wants to receive "Abort".
Please inform me whether program in V3 can receive ABORT_TX for .0 case.
Best Regards,
Jong-Ho Lee.
|
| 689.4 | The abort can be designed into the application | TALER::DESHMUKH | Dipankar Deshmukh, RTR (US) Engg | Sat Apr 19 1997 02:50 | 6 |
| Under V3, if the customer wants this transaction aborted, it
should expect the time sent back to it in a subsequent message
from the client. Then it can compare the time it sent back and
the time it got back from the client. If the two differ, then
the server can abort the transaction.
|
| 689.5 | thanks | DEKVC::JONGHOLEE | | Sat Apr 19 1997 07:26 | 6 |
| Thanks for your advice.
I'll recommend your application design consept to my customer.
regards.
Jong-ho Lee.
|