thanx for your input Jeffry >> At a high level, it sounds as if you are filtering queries based on the CompanyID.
yes, deep in the persist layer (it's always part of a join) >> If that is true, why not build your CFCs with the CompanyID as a parameter (which >> you can set from the session variable when initing the CFC). It was stated that you >> wanted to build some form of caching mechanism. I see nothing wrong w/ that. yeah, I was thinking the same thing with a dynamic name based on the company ID. so I'd end up with multiple instances based on session.company_id. I would still need each instance to know what it's company_id is. there'll be no shortage of memory available. so, instead of checking for a structkey within the cfc instance matching the company_id, i'd be looking for an instanciated company_id instance (and if the factory didn't find it in server scope, create and populate it). I'll have to think about it a bit more. Because it's server (shared) scope, there's RACE considerations to keep in mind... hmmmmm..... cheers barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
