Thanks, Jared, Tanel. I was a little supprised to see a combination rlbk=1,rd_only=1. Why read-only bit is set here if it rolls back anyway? So I thought may be they mark their tx explicitly as read-only (aka "set transaction read-only"). Reveiwing OCI fine manual there seemed to be an option of doing just that with the OCITransStart() call and setting some flags...
But than simple test-case of tracing commit and rollback in SQL*Plus disproved the theory about read-only tx, as "normal" commit/rollback produce this combination regardless of the tx type: commit - XCTEND rlbk=0, rd_only=1 rollback - XCTEND rlbk=1, rd_only=1 set transaction read only commit - XCTEND rlbk=0, rd_only=1 rollback - XCTEND rlbk=1, rd_only=1 So much for my theory :-( Another question I had here is whether or not having so many (implicit?) rollbacks on about every SELECT statement all over my trace file bears any overhead and proves deficiency of a stateless architecture used by this application - but again reviewing v$sesstat before and after I see user rollbacks count incremented, but no additional redo vectors generated. I guess I can try Tom Kyte's test harness, but it just doesn't sit well with me that 30 selects are as cheap as 30 selects with 30 rollbacks. Thanks, Boris Dali. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
