[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

1505.0. "FM making database calls?" by ESCROW::LANG () Fri Sep 13 1991 14:46

	I would like to write an FM which makes calls to a database.  The
	database could be SQL or PIR, we are not sure yet.  Will there
	be a problem with an FM making database calls directly?  This would
	be I/O, so I assume this would block the whole process.

	If this is the case, and it would block the process, are there
	standard ways to handle this? If required, we could have a database
	server, but I thought there might be other ways to implement this.

			thanks,
				Bonnie

T.R	Title	User	Personal Name	Date	Lines
1505.1	Don't worry about blocking the process...	TOOK::SWIST	Jim Swist LKG2-2/T2 DTN 226-7102	`Mon Sep 16 1991 09:06`	5
	Do it the simplest way. Disk I/O would have to be done in very large quantity by a very active MM with tons of threads running before you would notice a degredation due to process blocking. Asynch I/O becomes a requirement with slow (relatively) devices like network interfaces.
1505.2	More explaination?	WENDAL::LANG		`Wed Sep 18 1991 12:38`	10
	RE:2 This is very simple to implement, but why is this true? If a MM "must not use waited I/O services that suspend the execution of the MCC process" (good neighbor policy), then wouldn't database calls be violating this? thanks, Bonnie
1505.3		TOOK::SWIST	Jim Swist LKG2-2/T2 DTN 226-7102	`Thu Sep 19 1991 09:50`	12
	Some neighbors are worse than others. It depends on the tradeoff between performance degredation and development effort. There is a tremendous difference in time between long and short I/O waits. If your thread takes a page fault, that also stalls the whole process for disk I/O, but you wouldn't even think about trying engineer a solution to this problem! It just isn't worth the effort. All the DECmcc/Ultrix MIR and Dictionary accesses are process-synchronous. We've never seen a problem with this approach.
1505.4	re PIR on VMS	STAR::ROSENBERG	Duvie - On a buffalo wing and a prayer - ZKO3-2/Y05 (2Y08) - 381-1517	`Fri Sep 20 1991 11:51`	9
	Bonnie, As I understand it, the threads support within DECmcc will intercept certain system calls (under VMS) which are normally synchronous and use asynchronous forms to keep from blocking the entire process. The PIR implementation uses synchronous RMS calls directly and expects them to be massaged into asynchronous ones for it. Dave (just trying to be a good neighbor)