Instantiation is expensive, so you want to avoid it as part of request handling. It's not specific to CF and/or CFCs, DB connections have the same issue, and myriad other things do as well. The solution is a pool of already-instantiated object that are sitting unused. When you need an instance, instead of creating one from scratch (slow), you just pull an already ready instance from the pool (fast). That instance is yours forever, so you avoid the concurrency issues you currently have.
So you don't really save any time overall (you still have to instantiate everything), but you avoid having to do it while a client is waiting for a request. With CF, you'd probably set up a scheduled task or event gateway that runs every X time and ensures that your pool has enough instances, creating more if needed. If the objects are well suited, they can be released back into the pool after they're done being used, further reducing the number of instances that have to be created. That's not always possible, however, depending on the type of object. If you do this, then you'll also want your periodic check to ensure there aren't too many instances in the pool. If there are, you're wasting memory, and some should be killed off. cheers, barneyb On 10/25/05, Ryan Guill <[EMAIL PROTECTED]> wrote: > Alright, im with you on everything except for pooling. What exactly > do you mean by that? > > On 10/25/05, Barney Boisvert <[EMAIL PROTECTED]> wrote: > > No, you have a single instance and multiple references to it, where > > each reference is method-specific. You'll need to create a > > messageHandler instance inside each method and use it, rather than a > > global instance of it. I.e. change getMH to return a newly created > > instance instead of a shared instance. Since you're returning the > > data inside the messageHandler, there is no need for it to live longer > > than a single method invocation anyway, aside from the cost of > > instantiating them all the time, but that can be mostly mitigated by > > pooling. And that instantiation cost really isn't all that large, so > > I wouldn't even consider it until load testing indicates it's a > > bottleneck, and then you can consider pooling. > > > > cheers, > > barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
