Hi Craig,

LOL! No doubt. Apologies for the novel. I'm thinking aloud, so to speak.

Well, heres the deal, and maybe this just goes to show that I need a different design.

I have been experimenting with COM+ in order to reduce network traffic in a specific situation that came up in our LAN application. The original version is a regular LAN app that opens tables on a mapped nework drive that are used in a complex data entry form. The CDX file for the main table used in this form is maybe 50 MB, and I believe we were getting network traffic congestion when 6 or 8 people were making lots of changes to the table concurrently, (which is the purpose of tha form. They are entering 2004 property tax statements by the bucketload). It struck me that the bogging down is the result of repeatedly downloading a fresh copy of the updated CDX to the workstation as the changes made update it.

Here the COM+ server based DLL entered the picture. The goal is to move the process to the server to which that data is local, minimizing network traffic. I determined as an experiment, to code the functions performed in that same form into a COM+ component and test it for performance as the number of users increases. It is a rather fat component, and opens several tables. That part is why I wonder about releasing it a lot. Reinstantiating a new one would take a hit, as you say.

So, having made an instance in the form using CREATEOBJECTEX(), is it possible, or desirable for that one to end up being released, and reinstantiated? I am coding them in a stateless manner, so each method call wouldn't depend on anything having happened beforehand. Maybe adjusting the timeout setting in COM+ services to be longer than 3 minutes would prevent the situation I was fearing, which is that the thing went out of use during a data entry session due to timeout and then has to reopen everything occasionally, giving a weird random slowdown.

It strikes me that making a set of components mirroring the database structure would perform better, with a set(or one, in this test case) that uses those made to mirror the functions of the form. Bleh.


>You probably won't like the answer...it depends. One of the great things about COM+ is that it scales really well. It gets that from reusing components. If your app holds onto the component for too long, then you lose some of that scalability. Where the threshold is at depends on your configuration (server memory, actual length of instantiation, number of users connecting to your component, etc). This tells me that you want to keep the component instantiated for as little time as possible.
>
>However, the flip side is that the most expensive thing is instantiating the component in the first place. This means that if you continually instantiate and release a component, you'll take a performance hit.
>
>So...you'll have to do some testing for you particular situation. Is it better to instantiate the component, save the values someplace, then release it. Then instiate it again, read the values, etc... or is it better to instantiate the component and keep using the same one.
>
>However, you are correct that you'll only call SetComplete() when you have totally finished using that instance of the component.
>
>