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

Conference microw::acmsxp

Title:ACMSxp product questions and comments
Notice:Refer to notes 1 through 11 for conference information
Moderator:DUCAT::ROSCOE
Created:Tue Oct 05 1993
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:282
Total number of notes:1134

280.0. "Can't abort a transaction" by CSC32::J_HENSON (Don't get even, get ahead!) Wed May 14 1997 15:30

acmsxp v2.02 (with a patch), digital unix v3.2g, alpha

This is a problem reported by Canadian Tire Corporation.  They are 
running a patched version of acmsxp, but weren't sure of the proper
identification of the patch.  Neither am I.  However, the patch
was for the queue gateway, or something related to the queue gateway.

Recently, the acmsxp queue died and restarted itself.  Apparently,
this is something that happens often enough that the customer
has recognized certain symptoms and behaviors of this.  On such
behavior is that instead of the 'normal' 130 transactions in
the queue, there are 260 after the restart.  This is information
obtained by the command

tkadmin list transactions

Using the command tkadmin abort transaction <transaction id>, they
have been able to abort all but one of the holdover transactions.  When
they try to abort that one, the attempt fails with the following error.

call to tran_abort failed with a status enc-tra-0100:  The transaction
identifier that was pas as an argument did not meet the requirements for
this function.

When the 'look' at the transaction (not sure how they do this), it shows
to be in a committing state.

The want to get this cleaned up before tomorrow afternoon.  This is because
they plan to stop and restart sfs, and past experience has shown them
that sfs literally takes hours to start if there is a pending transaction
such as this.

Where do I go from here?

Thanks,

Jerry Henson
U.S. CSC
T.RTitleUserPersonal
Name		DateLines
280.1CAMINO::MCDERMOTTThu May 15 1997 12:5418
    Hi Jerry,
    
    We have been in contact with CT regarding this issue.
    
    CT has made there sfs log file much smaller, before when it
    was 4G bytes it did take hours to read thru the log.  The log 
    file is know is much smaller, 512k bytes, so in theory it should
    take only a fraction as long.
    
    CT's plans are if reading thru the log takes more than an hour they
    are going to re-create the tpsystem.                       
    
    I have placed a call to Transarc regarding the transaction that
    causes the error.  When I here from Transarc I will post there
    reply here.
    
    Greg
280.2force transaction instead of abort transactionCAMINO::MCDERMOTTThu May 15 1997 15:3118
    Regarding the error aborting transactions:
    
    You can not abort a transaction that is in the "committing"
    state.  Since it has already entered the two-phase commit
    cycle, its to late to abort.   
    
    You might be able to force the transaction with:
    
    tkadmin> help force transaction
    NAME
        tkadmin force transaction -- Force the outcome of a transaction.
    
    SYNOPSIS
        tkadmin force transaction [-server <server name>] <tid>
    [-commitdesired]   [-finish]
    
    
    Greg
280.3DUCAT::ROSCOEFri May 16 1997 09:2611
We talked with transarc about the time needed to read the logfile.  The sfs
server, when it starts, is able to determine immeadiately if the logfile is 
empty.  If it is then the server bypasses the reading of the logfile.  If it
is not then the entire file is read looking for transactions.  It is therefore
important to adequately size the logfile to keep the time reading the file
to a minimum.  CT had originally sized the logfile many times larger than they
needed, only recently did they scale the size of the file back to a more
reasonable size.  


Rich
280.4unable to delete this transactionCSC32::J_HENSONDon&#039;t get even, get ahead!Wed May 21 1997 12:4019
I just received an update on this.

CT did the following.

 -  used tdadmin to attempt to force the transaction to complete, as
recommended.  This didn't help.
 -  stopped the tp system
 - stopped sfs
 - used dce clean
 - restarted the tp system

This time, because their transaction log file is so much smaller, it
only took 5-7 minutes to start.  That's the good news.  The bad news
is that the bad transaction is still there.

At this point, it's more of a nuisance to the customer than anything
else, but it seems to me that it's an issue that needs to be resolved.

Jerry
280.5CAMINO::MCDERMOTTWed May 21 1997 13:186
    Hi Jerry,
    
    I made a call to Transarc regarding this issue.  As soon as I 
    here from them I'll post there reply here.
    
    Greg
280.6?CSC32::J_HENSONDon&#039;t get even, get ahead!Tue Jun 03 1997 10:3614
>>                     <<< Note 280.5 by CAMINO::MCDERMOTT >>>

>>    Hi Jerry,
    
>>    I made a call to Transarc regarding this issue.  As soon as I 
>>    here from them I'll post there reply here.
    
Greg,

Anything new on this?

Thanks,

Jerry
280.7CAMINO::MCDERMOTTThu Jun 05 1997 17:598
    Hi Jerry,
    
    Transarc was unable to provide any solution for getting rid of 
    the transaction.  Since the process that "owns" tid is gone there
    is nothing Encina can do about it.
    
    Greg