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

Conference ulysse::rdb_vms_competition

Title:DEC Rdb against the World
Moderator:HERON::GODFRIND
Created:Fri Jun 12 1987
Last Modified:Thu Feb 23 1995
Last Successful Update:Fri Jun 06 1997
Number of topics:1348
Total number of notes:5438

185.0. "Transaction Protection RDB vs Intact" by CSTEAM::WADSWORTH (KIRBY WADSWORTH) Mon Aug 29 1988 21:49

    I was told today that RDB offers transaction protection.  
    It was my understanding that DecIntact was incorporated into our
    DECtp products to fill a hole in transaction protection.  Would
    you please clarify this for me?  Thanks in Advance. 
                                                       
T.RTitleUserPersonal
Name
DateLines
185.1apples and orangesSAGE::OISPGKeith A: DESINE at ground zeroTue Aug 30 1988 17:0220
    I dont know DECIntact but doubtless an enthusiastic advocate will
    jump in and tell you about it.
    
    A point on relativity: products like ACMS, DECIntact are intended to be
    TP monitors that layer over databases, operating systems, etc. Hence we
    have to consider the definition of a "transaction" at each layer to see
    what that layer gives us in terms of protection. For example, an ACMS
    user may consider a certain activity to be one logical transaction but
    Rdb may be given several Rdb transactions to do for that single logical
    transaction. Rdb will look after each Rdb transaction but knows nothing
    about the ACMS logical transaction. If Rdb transaction R1 may be
    committed and then R2 will fail and be rolled back. This may cause
    a failure for the ACMS logical transaction L1 but there is no way
    (now) that Rdb nows that the previously committed R1 is invalid.
    
    This difference in meaning between transactions is the reason for
    discussion on 2 phase commit. Customers want a system where a high
    level component (like ACMS, DECintact) can easily coordinate
    transaction commits and rollbacks with lower levels like Rdb, RMS,
    DBMS etc.. 
185.2Logical Transaction CSTEAM::WADSWORTHKIRBY WADSWORTHTue Aug 30 1988 23:066
    Thanks .1
    As an old OLTPer, I view a transaction as a logical unit of work, not
    an  individual interaction with a database.  If I transfer money
    from my checking to savings, I want to be assured that the money
    went into my savings account after it was successfully removed from
    my checking account.   
185.3I don't think that's why we have DecIntactWIBBIN::NOYCEBill Noyce, Parallel Processing A/DThu Sep 01 1988 16:0210
    DEC database products have provided transaction protection for a
    long time: VAX DBMS V1 had it in 1981; VAX Rdb/VMS V1 in 1984.
    RMS didn't have it until RMS Journaling (1987?).  Intact was developed
    to fill this hole in RMS (and also to add some other things (hashed
    access?) that you probably know more about than I do).  DEC decided
    to buy Intact and re-sell it for reasons I don't entirely understand,
    but I'm sure that it's partly because it appeared to provide much
    better performance than ACMS did.  I don't think it gives any more
    transaction protection than are available in the database products
    and (finally) now RMS.
185.4CSC32::STENOISHJim Stenoish, VIA TBU, CSC/CSThu Sep 01 1988 20:237
    DECintact allows transaction integrity over multiple RMS databases,
    something neither Rdb or DBMS currently allow.  At the time DECintact
    was acquired, ACMS had no transaction integrity if your database
    wasn't all in 1 file Rdb or DBMS database.  Of course, DECintacts
    rollback/rollforward recovery facilities is not currently integrated
    with Rdb's or DBMS' recovery facilities, so there doesn't seem to
    be any advantage to using DECintact with Rdb or DBMS.