|
|
|
MAX_USER_LOGS <max number of logs>
MAX_USER_LOGS controls how many logs a transaction can span before attempts are made to abort or abandon the transaction. The default, ZERO, disables the check for long transactions.
If a transaction cannot be aborted (for example, a server fault would occur) the transaction is abandoned which means that the client thread loses its connection to the server. There is no guarantee that the transaction will not span more logs than the specified maximum, but the transaction will end within a reasonable number of logs.
If the transaction is aborted, then the next call by the client will return a MLAB_ERR (821) to indicate the operation was not completed and the pending transaction has been aborted. A message of the following form will be made in CTSTATUS.FCS:
Sun Dec 03 08:53:21 2006
- User# 00011 Transaction aborted at ct_mul_abandon1 for user# 9: 821
If the transaction is abandoned (which means no explicit abort written in the log), then the client will be disconnected from the server. CTSTATUS.FCS entries such as those shown below reflect logs growing from a transaction that is pending, then the detection of the long transaction, then the eventual abandonment:
Sun Dec 03 09:53:42 2006
- User# 00012 The number of active log files increased to: 5
Sun Dec 03 09:53:42 2006
- User# 00012 Transaction (started in log 1) still pending.
User# 11 |GUEST||
Sun Dec 03 09:53:55 2006
- User# 00012 The number of active log files increased to: 6
Sun Dec 03 09:53:55 2006
- User# 00012 Abandoned Transaction
Sun Dec 03 09:54:10 2006
- User# 00012 The number of active log files increased to: 7
Sun Dec 03 09:54:10 2006
- User# 00012 Abandoned Transaction2
Sun Dec 03 09:54:10 2006
- User# 00012 Abandoned transaction kill request posted against user #11
|GUEST||
Sun Dec 03 09:54:10 2006
- User# 00011 ctntio: send error - O11 bytes=0 pErr=127
|GUEST||: 168
Sun Dec 03 09:54:25 2006
- User# 00012 The number of active log files decreased to: 4
The number of logs continued to grow, and then shrink, as reflected in the above excerpt because in addition to a transaction sleeping on a blocked lock, another unrelated application was continuing to add records to its files and corresponding entries in the transaction logs.
