[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

141.0. "Distributed Transactions with RDB?" by HSK01::MANNISTO (Olli Mannisto, SWAS/SW Technology, Digital Finland) Fri May 27 1988 14:44

    
    VAX Rdb/ELN v2.1 document states:
    "A user can update two or more databases such that if there
    is an error, neither database is updated. That is, each set of
    changes is atomic across all databases in the transaction, thus
    providing data integrity across the network. The problem of one
    database becoming inconsistent with respect to the data in
    another database has been solved."
    
    Is this really true (now) for Rdb/ELN? And for VMS RDB?
    
    
    -- Olli

T.R	Title	User	Personal Name	Date	Lines
141.1	not yet	BANZAI::BERENSON	Rdb/VMS - Number ONE on VAX	`Fri May 27 1988 15:14`	9
	Rdb/ELN sort of provides this however the support is incomplete (if you modify 2 databases and commit and one update fails at just the right point in time, the other may be committed while the failed database is in limbo until some kind of manual magic recovery). Rdb/VMS does not have the capability at all right now (if you modify 2 databases and commit and one update fails, the other may succeed).
141.2	What is the transaction ?	OSKV01::KATOH	Hiromu Katoh/SWS/Osaka/Japan/	`Wed Jun 01 1988 04:00`	24
	>Rdb/VMS does not have the capability at all right now (if you modify 2 >databases and commit and one update fails, the other may succeed). Rdb/VMS always return a success condition in RDB$PREPARE_TRANSACTION. It means Rdb/VMS doesn't support 2 phase commit yet. But I don't know what happen in the following case. 1. invoke db1 2. invoke db2 3. start_tran read_write 4. modify db1 5. modify db2 6. commit When error occured at no5, does db1 update fail or not ? When error occured at no6, which database update fail ? 2 databases are located in the same node, the result is the same or not ? In multiple databases what is the transaction ? I'm comfused. Thanks, Hiromu Katoh
141.3	Except for Error Cases, You can update 2 DBs	BANZAI::BERENSON	VAX Rdb/VMS Veteran	`Thu Jun 02 1988 00:12`	31
	>1. invoke db1 >2. invoke db2 >3. start_tran read_write >4. modify db1 >5. modify db2 >6. commit > >When error occured at no5, does db1 update fail or not ? If the application issues a ROLLBACK after the failure, then the update to DB1 is also rolled back. >When error occured at no6, which database update fail ? Either or both. Rdb/Dispatch (RDBSHR) will commit the databases participating in the transaction in some sequence (and I don't know the actual sequence). So, first it tries to commit DB1. If the commit of DB1 fails, then it returns an error and never tries to commit DB2. However, if the commit of DB2 succeeds it then tries to commit DB1. If the commit of DB1 fails, you now have part of the transaction committed and part aborted. >2 databases are located in the same node, the result is the same or not ? The same problems can occur on a single node as on multiple nodes. The system could crash, a disk could go down, or a commit-time constraint could fail, leaving one database committed and the other not. >In multiple databases what is the transaction ? I don't understand the question.
141.4	Thanks	OSKV01::KATOH	Hiromu Katoh/SWS/Osaka/Japan/	`Thu Jun 02 1988 04:03`	14
	Thanks, I got it. >In multiple databases what is the transaction ? >>I don't understand the question. Thansaction is logical unit of work. So if I want the database keep consistency, the logical unit of work update all or nothing. In previous case, each database keeps consistency but the system ( 2 databases) is inconsistency. Is the transaction for each database or for system (2 databases) ? Hiromu
141.5	Depends on how you look at it!	NOVA::BERENSON	VAX Rdb/VMS Veteran	`Thu Jun 02 1988 17:43`	3
	From a consistency standpoint there are two separate transactions. From a programming viewpoint there is a single transaction which, at the DSRI level, has a single transaction handle.