Browse Prior Art Database

Object Pooling Mechanism Capable of Supporting Dynamic, Programmatic Object Factory Reconfiguration

IP.com Disclosure Number: IPCOM000033208D
Original Publication Date: 2004-Dec-01
Included in the Prior Art Database: 2004-Dec-01
Document File: 4 page(s) / 76K

Publishing Venue

IBM

Abstract

Disclosed is a mechanism that addresses the pooling of objects created by an object factory with dynamically reconfigurable properties. Because object factory properties are inherited by the objects the factory creates, a mechanism is needed to distinguish between objects created under each different factory configuration for purposes of efficient object pooling.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 33% of the total text.

Page 1 of 4

Object Pooling Mechanism Capable of Supporting Dynamic, Programmatic Object Factory Reconfiguration

Objects are not able to be reused from an object pool when the object factory that created them is programmatically modified. This results in inefficient object pooling due to the need for creation of new objects every time the application modifies object factory properties.

     When object pooling is used, objects can be pooled and reused based on the various properties of the pooled objects. In situations where the object factory includes properties inheritable by the objects it creates, object pooling also needs to take into account the inherited properties of the factory. Objects to be pooled are generally created by a single factory, but if the factory configuration changes, objects created by the object factory prior to the reconfiguration are not equivalent to objects created afterwards. Historically, to account for changes to the factory configuration, existing objects in the object pool were destroyed and new objects were created as needed under the new configuration. Then, once the factory switched back to its original configuration, the object pool would be cleared out yet again, to ensure pooled objects with the wrong factory configuration were not used. Clearing out the pool with each change to the object factory in situations like this is very inefficient, as it partly defeats the purpose of object pooling.

     The idea behind this proposal is to provide information about the factory configuration on the connection pool matching criteria for the objects themselves. This allows reconfiguration of the object factory without requiring the discarding of objects created under previous factory configurations. Consequently, it is possible to take advantage of the performance enhancements provide by object pools, even when object factory configurations change frequently.

     Specifically, WebSphere* Application Server (WAS) encountered a problem with the pooling of database connections. WebSphere Application Server needs to make the Connection Factory (referred to as a DataSource) support dynamic, programmatic configuration changes. At the same time, the connections created by the Connection Factory need to be pooled by a J2C Connector Architecture (JCA) connection manager. A getConnection request to a Connection Factory is passed a set of properties which are set on the connection as needed. These properties are different from the properties of the Connection Factory. The JCA connection manager essentially created separate object pools based on these Connection Factory properties. However, the JCA connection manager is designed to work with a single Connection Factory, so when the properties of the Connection Factory changed, all of the connections in the pool had to be destroyed. Because of the performance implications, Connection Factories were not allowed to be modified once they were initialized.

     We designed a way to associate the co...