[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

669.0. "How to interrupt an server when it is not waiting" by HGOVC::MICHAELWAN () Thu Jan 30 1997 09:25

    I am looking for a way to interrupt the server process when the
    requester has aborted the transaction. 
    
    When the requester has aborted the transaction (e.g. user decides to
    cancel tx due to a long wait time) but the server process (may be
    in another machine) is working on a long operation and is not waiting
    for reply from RTR, how can I interrupt the server immediately. 
    
    I've checked the list of RTR events that will deliver an interrupt to
    the server but aborting a tx will not generate an event. 
    
    I want to interrupt the server immediately so that it won't affect any
    resubmitted or new transactions. (e.g. locking problem)
    
    I need the answer both on VMS and UNIX.

T.R	Title	User	Personal Name	Date	Lines
669.1		AMCFAC::RABAHY	dtn 471-5160, outside 1-810-347-5160	`Thu Jan 30 1997 17:31`	7
	On OpenVMS, depending on how big a hammer you want to use, try STOP/ID. This is not as drastic as pulling the plug. Still it is most likely not what you were thinking. In band, I would try doing the DB operations in a seperate thread from the RTR functions. Then when the abort is detected just interrupt the DB thread. Is the DB compatible with a threads package that RTR is also compatible with?
669.2	The question is on how to detect.	HGOVC::MICHAELWAN		`Fri Jan 31 1997 09:54`	5
	Thanks for the reply. But my question was not on how to stop the server process (although suggestions are welcome) but on how to detect the abortion immediately if the server is not waiting for RTR's reply?
669.3		AMCFAC::RABAHY	dtn 471-5160, outside 1-810-347-5160	`Fri Jan 31 1997 19:20`	29
	My testing shows that RTR will let the server $ENQ_TX a reply whilst a $DEQ_TX is still outstanding. So, the following logic is a way to detect the abort right away; normal ------ requester server --------- ------ $dcl/req $dcl/ser $start_tx $enq_tx $deq_tx fork(DB) $deq_tx $enq_tx reply (this happens after the following $deq_tx) $commit $deq_tx $vote_tx/commit aborted ------- requester server --------- ------ $dcl/req $dcl/ser $start_tx $enq_tx $deq_tx fork(DB) $deq_tx ($enq_tx reply never happens) ... (either the $start_tx had a timeout or some other mechanism effectively leads to the following explicit or implicit $abort_tx) $abort_tx $deq_tx kill_fork(DB)
669.4	Other alternative	FFRANC::DESHMUKH	Dipankar Deshmukh, RTR (US) Engg	`Sat Feb 15 1997 00:04`	7
	Another alternative is to post an asynchronous DEQ_TX before starting the DB operation. If the transaction aborts, an AST will fire and the application will be told. The problem is that the AST will also receive the next message or the VOTE request. The application has to take care of these cases. -dipu-