Even if the Invoice object had some functionality where code is being executed without a caller, that would mean the Invoice object would have to run that code itself. When does it do that, in its constructor? Maybe that’s what you mean… in that case you should simply make the Invoice object start its own thread for its own code, so that it doesn’t block the thread in which it is constructed - but that’s still not the main thread most of the time; it should be the thread where the new object gets constructed, which would depend on the growing mechanism(s) you have in your pool.

Thanks,
Shawn

Anyway, I have a method “GetInstance()” that returns an instance of type T (in List) (in this case, Invoice). These are heavy objects.

So… InvoiceObjectPool lives in Application[] of ASP.NET. When my page request says:

Invoice = InvoiceObjectPool.GetInstance();

it is actually creating or reusing an instance that was created and resides on the same thread that Application[] resides in.

That said, all of the functionality that Invoice respresents, is actually being executed on the main thread, not the thread servicing the Request. Thus, it is a bottleneck in a high load environment.

Using a ReaderWriterLock (or the lock() in your case) on the object pool assists with locking issues for creating/removing items from the pool (in ASP.NET) but not which thread the object in the pool executes in (it is not actually executing on the working/Request thread).

Hope that clarifies.

Thanks,
Shawn

Now, when a request comes in in the form of a call to GetObject(), the code in the GetObject() method is executed in the thread of the caller, which is why I protect access to the management structures from that code with a lock.

Finally, when an object is returned to the calling object by the GetObject() method, the caller will presumably “use” that object for whatever it’s intended to be used for. Any executions of code in the pooled object will then occur in the thread that the caller is running in, be that a Page’s thread or whatever else.

If you look at the origin of the objects in the pool, you might find that they were all created on very different threads - the first few might have been created when the pool was created, any number of others were possibly created when the pool ran dry within a GetObject() call, so this would have happened on the thread of the caller that just happened to call at that moment. But an object is just a piece of data, it doesn’t “belong” to a specific thread, so there shouldn’t be a problem as long as the object is only ever used by one caller at a time - something that the pool should guarantee, as well as it can.

So, maybe these explanations help you? If they don’t, maybe I’m missing something that’s specific to ASP.NET - or could you explain the problem you’re seeing in more detail?

When I put a pool in the Application (or Cache) space in ASP.NET, each page is contending for an object from the pool, but will execute the object on the same thread as the Application/Cache space (which is not the same thread as the page). Needless to say, performance wasn’t all that rockin’.

The only way I know of to solve that is that have a custom thread pool (so as not to starve ASP.NET by using the default ThreadPool) and have each instance reside on its own thread. What’s your take?

Thanks,
Shawn