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

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

1114.0. "INGRES / SQL access in a VMS MM" by TENERE::BOURGADE (BOURGADE Jean-Michel, European EMA SVP Engineering) Fri Jun 07 1991 13:13

Hi,

	With one of our EMA partner, we have started using INGRES / SQL through
a management module on VMS ( later on ULTRIX ).

	This case will not be the last, others consider Oracle... The reason
is that most of them had already DB based applications or management systems,
before to become partners, and that the MIR object oriented technology has a 
too poor query language compared to relational technology, when you consider
using DECmcc for administrative applications.

	Any experience / guidelines in this domain ( INGRES ) would be helpfull.

	Can anyone point the constraints / benefits in regard to RDB : 
access through submitted process ( by pipes ) or direct calls in the MM...


	Thank you for any clues,

	Jean-Michel ( EMA SVP Europe )

T.R Title User Personal
Name Date Lines

1114.1 threads, threads, threads TOOK::SWIST Jim Swist LKG2-2/T2 DTN 226-7102 Fri Jun 07 1991 13:34 18

T.R	Title	User	Personal Name	Date	Lines
1114.1	threads, threads, threads	TOOK::SWIST	Jim Swist LKG2-2/T2 DTN 226-7102	`Fri Jun 07 1991 13:34`	18
	Your biggest problem using a dbms from an MCC access module is that most databases aren't very thread-friendly. They're rtl's are not re-entrant which will give you a problem with pre-emptive thread systems like dce-cma (which we use on DECmcc/Ultrix and now and on DECmcc/VMS soon). And they have further restrictions on concurrency - Ultrix/SQL (ingres) allows only one outstanding transaction per db connect (Rdb was the same way last I looked at it but it's been years). Even if you structure you code to do a connect per thread, you have serious scalability problems as each connect uses many resources. We actually managed to get Ultrix/SQL running as the underlying MIR implementation on MCC/Ultrix (and on Ultrix 4.0 to boot, where you had a max of one transaction per process), but the implementation is ugly ugly and uglier with all kinds of crazy mutex and transaction management schemes. Until databases get more attuned to real-time applications, my only comment is that it's doable but it isn't fun.....

    Your biggest problem using a dbms from an MCC access module is that
    most databases aren't very thread-friendly.  They're rtl's are not
    re-entrant which will give you a problem with pre-emptive thread
    systems like dce-cma (which we use on DECmcc/Ultrix and now and on
    DECmcc/VMS soon).  And they have further restrictions on concurrency -
    Ultrix/SQL (ingres) allows only one outstanding transaction per db
    connect (Rdb was the same way last I looked at it but it's been years).
    Even if you structure you code to do a connect per thread, you have
    serious scalability problems as each connect uses many resources.
    
    We actually managed to get Ultrix/SQL running as the underlying MIR
    implementation on MCC/Ultrix (and on Ultrix 4.0 to boot, where you
    had a max of one transaction *per process*), but the implementation
    is ugly ugly and uglier with all kinds of crazy mutex and transaction
    management schemes.
    
    Until databases get more attuned to real-time applications, my only
    comment is that it's doable but it isn't fun.....