对象池(Object Pooling)和即时激活(Just In Time Activation)是COM+提供的两种不同的实例管理机制。似乎有很多人对COM+中的对象池和JITA的设计思想不太了解，甚至有所误解，这里随便说几句。
池(Pooling)是一种很常见的设计思想，池即缓冲，对象池即COM+对象(必须是可以池化的)的缓冲区。一般认为，所谓池化缓冲用以优化访存效率，然后我觉得这句话表达还需更进一步：池化缓冲是用来控制池化对象创建代价、提高对象重复利用率，从而实现优化访问效率优化的。换而言之，池化缓冲机制应用于创建代价极其昂贵的对象管理之上最为有效，其本身就是为了避免创建代价昂贵的对象不断地被反复创建而提出的，其优化的参数可以直观的定义为：对象重复利用次数/对象创建次数，该值越大则优化效果越明显。有经验的朋友可以联系数据库连接池、调度线程池等池化应用实例想想看，其无一不是针对上述类似的应用场合。
而即时激活(JITA)这种设计思想很多人则表示不理解了。JITA是指：客户端一直维护着一个关于COM+对象服务器的代理引用，它并不知道该服务器当前究竟是否是处于实例化状态的，当它引用这个COM+服务器时，COM+将即时地激活一个服务器对象(即生成一个对象服务器的新实例)，当客户端引用完毕之后，该服务器对象马上被COM+所钝化(Deactivation)，进而销毁。JITA机制是池化缓冲的极端对立面，也就是说，JITA是用来控制稀缺资源实例化(独占)时间、进而提高对象重复利用率的，其优化参数可以定义为：稀缺资源利用次数/稀缺资源平均独占时间，该值越大则优化效果越明显。JITA机制适用于于对象创建代价不甚昂贵、然而其独占的资源却极其有限的应用场合。
最后，说一点我自己的体会，举个具体的例子。在一个普适性(Pervasive)要求很高的分布式信息处理系统(如银行系统)中，需要支持的客户端种类可能很多，既有B/S方式的Thin Client(如在线银行客户服务)，又存在着C/S方式的Rich Client(如银行营业台用机)，在这种应用环境下，可以采用池化缓冲的方式提高海量瘦客户端对后端COM+服务器/数据库的访存效率，客户浏览器的请求一般均为短期在线提交，因而其对服务器端资源的独占性不强，而可重复利用性较高；而针对有限数量的银行营业台终端，则应当采用JITA机制优化其后端的访存效率，长期在线的营业台终端对稀缺资源的长期独占性对整个系统的影响不可忽略。 在具体应用当中，池化缓冲和JITA并不相互排斥，完全可以把两者结合起来，如对象钝化之后不是完全销毁，而是放入缓冲池中等，以实现更高的资源利用率和访存效率。