[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference decalp::rtrnotes

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

676.0. "How tnx is processed in case of failure of Router ?" by DEKVC::DONGWONSHIN () Thu Feb 13 1997 09:19

When the standby router takes over the current transaction because of failure 
of active router, does it always copy whole previous transactions logged in the
current transaction block from Journal file in order to keep consistency with 
REPLAY buffer of standby router before retransmitting the failed transaction?
If not, is the only transaction that was sent at the latest to the previous 
router retransmitted ? 

Thanks in advance.
	
	/dong-won

T.R	Title	User	Personal Name	Date	Lines
676.1	journal shouldn't be involved at all	DECALP::KLAVINS	Ed Klavins, RTR Engineering	`Fri Feb 14 1997 02:35`	11
	If a router fails, then any transactions that were in progress and using that router will be taken over by another router. Briefly, the RTR frontend detects that it's router has failed and tries to find another router. After having found a new router, the frontend will replay the transaction through the new current router (the frontend keeps a copy of the TX until the router tells it the TX has been committed -- it is thus capable of replaying the TX in circumstances such as these). So in general, the journal is not involved in recovering from these types of failures. ed
676.2	Then when rtr use the journal information ?	DEKVC::DONGWONSHIN		`Mon Feb 17 1997 01:28`	11
	Thanks, I don't have much knowledgable about RTR, so please give me some more information. As you mentioned earlier, I can understand your answer for router failure senario. However in ths case, there is still question about when RTR uses the journal information. In my understanding, router has also information for the TX from frontend, so even backend is gone down, router can retransmitt the failed transaction again to the standby server without journal information. So can you give me when RTR use the journal information ? Thanks alot.
676.3		DECALP::KLAVINS	Ed Klavins, RTR Engineering	`Mon Feb 17 1997 07:58`	12
	Journal comes into play once the router has told the frontend that the TX has been committed (because then the frontend deletes it's copy of the TX). The router still has to confirm with each of the backends that it has committed it's TX -- if anything happens to network or backend at this time, then the TX will have to be recovered from the journal (these are the "uncertain" TXs). Journal is also used for shadowing configurations (if one part of the shadow pair is unavailable, for example, it needs to remember the transactions). ed.
676.4		AMCFAC::RABAHY	dtn 471-5160, outside 1-810-347-5160	`Tue Feb 25 1997 16:05`	25
	The journal can be thought about as a durable copy of the frontend context. Technically it is a write-ahead-log. A frontend is not given a commit status until the messages of the transaction are hard flushed to the journal. requester server --------- ------ $dcl_tx/req $dcl_tx/server $start_tx $enq_tx $deq_tx DB operation $commit_tx $deq_tx $vote_tx/commit DB commit $deq_tx or $dcl_tx/shut The journal is required to close the window between the time the server votes to commit and it commits the underlying database. Only after the next $deq_tx or $dcl_tx/shut can RTR know that it is safe to release the transaction from the journal. Once the commit is sent to the requester, RTR can't count on the frontend resending in the event of a failure. When the RTR commit and the DB commit are made atomic with DECdtm then I suppose the journal becomes redundant. The DB commit, in fact, is also redundant. A DB recovery process will determine the transaction state from DECdtm. It won't blindly rollback and so require a replay.