On Tuesday, October 16, 2001, at 08:37 AM, Wilson, Doug wrote: >> 1a - In terms of efficiency, should different processes all >> be using the >> same statement handle? > > Different processes can't use the same statement handle. >
This was a typo on my part. What I meant was should 2 different modules within the same process each get their own database handle. And the answer is: "Always, no. This is because in a sequential execution model it offers no advantage and simply wastes another db connection". However, on Freshmeat today the following was announced, but I would appreciate any references to discussions on multiprocessor database connection caching and pooling under DBI. � �http://www.fatalmind.com/programs/ResourcePool/bigpicture.html ResourcePool - The Big Picutre The ResourcePool package include three major parts: * ResourcePool and subclasses * LoadBalancer * Singelton ResourcePool The ResourcePool is used to manage a pool of persistent connections (or more generally "resources"). Every resource in a pool is exaclty equivalent since the are created throu the same factory. If you want to make a pool of different resources (e.g. connections to differente databases) you have to use the LoadBalancer. The ResourcePool uses two other classes to operate: * ResourcePool::Factory to create Resources * ResourcePool::Resource as wrappers to implement a uniq interface to all resources The consturctor of a ResourcePool takes a Factory (and options). It uses this Facotry to create Resources as required. The Resources itself creates the finally interesting objects like DBI or Net::LDAP and provides a standard way to perform the common operations: close, precheck, postcheck,... If you don't plan add new resources types to the ResourcePool you will not get in touch with the ResourcePool::Resource classes. The ResourcePool::Factory and ResourcePool::Resource classes are only abstract base classes to inherit the specialized classes for your resource from. The ResourcePool supplies the get() method to get an connection out of the pool and a free() method to hand a connection back to the pool. Additionally you can us a fail() method to hand in a failed connection and tell the pool to not uses this connection again. The ResourcePool has the possibility to do a simple "ping" on connections to check if the resource is still valid. The detailed documentation can be found in the manpage. LoadBalancer The LoadBalancer takes one or more ResourcePools and uses them according to one of the Policies "RoundRobin", "LeastUsage" or "FallBack". Besides the construction the LoadBalancer is used in the same way as a ResourcePool. Have a look at the manpage for some examples. Singelton The Singelton class is an assistance to implement the ResourcePool. You can use the ResourcePool without understanding of Singelton. If you want to extend the ResourcePool you have to know about this class. The Singelton class is basically an implementation of the same named pattern from "Design Patterns", Gamma, Helm, Johnson, Vlissides - Addison-Wesley 1995 ISBN 9-780201-633610. This implementation of Singelton uses a static namespace to seperate different types of objects. See the manpage for a detailed description and an example. [ Back ] Last modified: Mon�Oct��8�21:39:54�2001
