From: jwd@rivm.nl (Jan Diesel)
Subject: Re: Transaction Log File
Organization: R.I.V.M.
X-Newsreader: Tin 1.1 PL5
Date: Mon, 11 Jan 1993 10:47:14 GMT

Steve Caswell (sfc@tpghq.com) wrote:
: In article <C0J1q9.FvG@rivm.nl> jwd@rivm.nl (Jan Diesel) writes:
: >David Kaplan (djk@sei.cmu.edu) wrote:
: >: 
: >: I'm having some intermittent problems with the Trasaction Log File.  Or,
: >: rather, it's having trouble with me?  In either case, the following error
: >: occurs when running a rather long set of queries:
: >: 
: >: **** ERROR: E_US1262 Your transaction has been aborted due to the transaction
: >:     log file having reached one of the limits set by the system administrator.
: >:     These limits are log_full, force_abort, and 90 percent of force_abort
: >:     when using the fast_commit option to start DBMS servers.
: >:    (Thu Jan  7 12:21:39 1993)
: >: 
: >: What's this all about.  I mentioned intermittent because some days I get the
: >: error, and other days I don't?!  There are commits after each query (all
: >: creation and insertion commands), and the queries are broken up just about as
: >: far as we can get them.
: >
: >The transaction logfile is used not only by inserts, updates and deletes but
: >by selects as well. The obvious solution to your problem seems increasing the
: 
: Unless something drastic has changed, selects ARE NOT LOGGED to the log file.

Sorry about this, you're right. I don't know where I got this information, and
I can't find anything about it in the manuals (they keep talking about 'all'
transactions).

: 
: >size of the transaction logfile or decreasing the size of your transactions.
: >The latter can be done by setting autocommit on (thereby causing each statement
: >to be treated as a singleton transaction). If this won't help and you don't
: >want to increase the transaction logfile you'll have to split up your statements.
: >
: Setting autocommit on is not a good thing to do in normal application
: situations.  This command is in INGRES primarily as a conversion tool to allow 
: converted release 5 applications to behave under 6 as they did in 5.  Using 
: set autocommit on in a production 6 application is not a good idea for three 
: reasons:
: 
:    1.  It is NOT ANSI standard.  It in fact makes transaction semantics behave
:        exactly opposite of ANSI standard.  If someone comes in later to
:        maintain your code, and is not aware that set autocommit on has been
:        executed, and is expecting ANSI transaction semantic behavior, they will
:        be in for a rude surprise.
: 
:    2.  Because set autocommit on is a conversion feature, there is no guarantee
:        that is will be supported in the future when Ingres decides that everyone
:        has converted and they remove the command.
: 
: 
:    3.  You lose rollback capability.  Unless EVERY statement in an application 
:        is a single statement transaction, you are giving up a lot.  Even if
:        every statement is a single statement, the incremental cost of putting
:        in a commit statement is minor.

I agree with you on most points. However I do think 'autocommit on' is a usefull
feature. By setting the 'default' to singleton transactions the logfile is not
clogged with transactions from (end-) users who don't know (or care) about
transactions. The point I'd like to make is to use 'autocommit on' just for this
'default' behavior, in (all) applications 'set autocommit off' ought to be the
first ingres-statement. This also prevents problems should Ingres decide to stop
supporting autocommit (which I hope they won't).

: >: 
: >: Could this error be an indicator that something else is wrong?  The fact that
: >: it is intermittant EVEN when the data being used has not change is what really
: >: has me puzzled.
: >: 
: >: Any clues appreciated ;-)
: >: 
: >: Thanks,
: >: 
: >: -Dave.
: >: 
: >: 
: >: ---------------------------------------------------------------------------
: >: David J. Kaplan                                             djk@sei.cmu.edu
: >: Software Engineering Institute                         dk3g+@andrew.cmu.edu
: >: Carnegie Mellon University                                   (412) 268-7736
: >
: >Regards,
: >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
: >Jan Diesel                                       |          jwd@rivm.nl
: >Informatics Service Centre                       |  tel. ++31 30 742067
: >P.O.Box 1, 3720 BA  BILTHOVEN, the Netherlands   |  fax. ++31 30 282316
: >RIVM - National Institute of Public Health and Environmental Protection
: 
: 
: -- 
: 
: Steve Caswell           |   (404) 448-7727    |  "The opinions expressed are my
: Principal Consultant    |   sfc@tpghq.com     |   own.  They may not be perfect,
: The Palmer Group        |   uunet!tpghq!sfc   |   but they're all I've got."

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jan Diesel                                       |          jwd@rivm.nl
Informatics Service Centre                       |  tel. ++31 30 742067
P.O.Box 1, 3720 BA  BILTHOVEN, the Netherlands   |  fax. ++31 30 282316
RIVM - National Institute of Public Health and Environmental Protection