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

Conference ilbbak::ibi_focus

Title:	FOCUS, from INFORMATION BUILDERS

Moderator:	ZAYIUS::BROUILLETTE

Created:	Thu Feb 19 1987
Last Modified:	Mon May 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	615
Total number of notes:	1779

316.0. "100 users?" by WOTVAX::MEAKINS (Clive Meakins) Fri Feb 23 1990 06:19

    Can anyone advise me as to the applicability of FOCUS with Rdb for
    large numbers of users?
    
    I know the applications need to be well written and the db well
    designed, my question revolves around the ability of FOCUS in the area
    of locking / concurrency.  Many 4GLS lock more than they need and it is
    often not possible to modify their behaviour (as it is with 3GLS).
    
    We are looking for, maybe 100 concurrent users.  My gut feel is to say,
    write the main application in a 3GL with FOCUS for the others.
    
    Any comments?

T.R	Title	User	Personal Name	Date	Lines
316.1	100 users is going to be tough	IJSAPL::WOODROW	Father of DRS	`Mon Feb 26 1990 03:47`	28
	> Can anyone advise me as to the applicability of FOCUS with Rdb for > large numbers of users? FOCUS (nor any other 4GL) can really "control" the Rdb locking except implicitly through the queries it builds (which you can "see" by setting RDMS$DEBUG_FLAGS to "B" - this displays the Binary Language Representation of every "query" that FOCUS sends to Rdb). The real problem right now is that FOCUS "violates" the recommended way of working with Rdb - namely, to fetch a record in a read-only transaction, allow the user to modify it, start a read-write transaction, reread the record to check unmodified and then do the actual update. FOCUS does not permit control over the transaction - in MODIFY it is always read-write (and it is very unreasonably to switch between TABLE and MODIFY). According to IBI, you might be able to simulate the above with a FOCUS COMMIT after the first fetch (to release locks), but we haven't tried it. The other problem, of course, is that each user has his own large process. For 100 users active you are going to need a LOT of memory. ACMS has been recommended at the 6 user breakpoint. Hope this helps. Peter
316.2	My 2-cents	WJOUSM::VEZINA		`Mon Feb 26 1990 09:22`	24
	We're currently running Focus on top of Rdb and have ran into a few interesting problems. We have a fairly large Rdb database, over 100,000 blocks with only a few users (4 or 5). Because of Rdb requirements, we're had to increase our users' account process quotas in their accounts. (You refered to locking / concurrency - we've increased our users' Enqlm to 1800.) Even with our small number of users, increasing their account process quotas have just about brought our system to its knees at times. With a 100 users, this would be a nightmare. I hope your Rdb database is not large! Another word of advice: Make sure the number of buffers in your Rdb database is less than your users' BIOlm and DIOlm account process quotas. We found this out the hard way.... Our users would be running Focus and their process would suddenly be killed! Another interesting thing we discovered is that Focus is using twice as many resources to run a query than RDO does! We ran the same RDO and Focus query against our Rdb database and RDO used half the CPU time, less than half the peak working set size and peak page file size, also less direct and buffered I/O. We're currently working this with IBI. Maybe our .mas and .acx files aren't as efficient as they can be. Hope this helps, Kris