Browse Prior Art Database

Process of Pooling Persisted Objects

IP.com Disclosure Number: IPCOM000035508D
Original Publication Date: 2005-Jan-21
Included in the Prior Art Database: 2005-Jan-21
Document File: 1 page(s) / 28K

Publishing Venue

IBM

Abstract

This publication describes a new coding practice which combines the process of persisting objects with the process of object pooling.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 1

Process of Pooling Persisted Objects

The current method found in most software applications for maintaining the state of a persisted object is a brute force serialization/deserialization of the object. After being persisted into a different form, the object is thrown out. When that object is needed again, a new instance of that type of object is created. However, in many cases the performance of an application would be better if the process of persisting particular objects could involve retrieving those objects from a pool, rather then going through the expensive operation of creating a new instance of that object.

Below you will find a description of one possible implementation of this invention in the Java language. Please note that this is not the only way that this new coding practice could be implemented. This explanation of one possible implementation is given to better define the art.

A class I will refer to as the PersistedObjectsPool will be in charge of managing the pool(s) of objects in the storing and loading process. Each class that wishes to take advantage of the PersistedObjectsPool would implement two methods I will refer to as storeObject and loadObject, each taking parameters for the Object Stream to read/write to, and an instance of the PersistedObjectsPool.

In the store process:
1. The application would call storeObject on the PersistedObjectsPool, passing the top level object A it wishes to store along with information on where the data should be persisted to (or the output stream itself).
2. PersistedObjectsPool would then call storeObject on the object A that it wishes to persist.
3. First object A would write its class name to the output stream as a String.
4. Next, object A would save off its state data to the output stream in whatever form most appropriate. This may include optimizations such as saving only non-default state. It may also include ne...