Ah, I see what youre talking about. That wouldnt be too hard either, just adding a reset() method to the messageHandler(). Ill play around with that, thanks!
On 10/25/05, Barney Boisvert <[EMAIL PROTECTED]> wrote: > 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] > > > -- Ryan Guill BlueEyesDevelopment [EMAIL PROTECTED] www.ryanguill.com (270) 217.2399 got google talk? Chat me at [EMAIL PROTECTED] The Coldfusion Open Application Library - COAL - http://coal.ryanguill.com www.ryanguill.com/ The Roman Empire: www.ryanguill.com/blog/ ---------------------------------------------------------- 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]
