Browse Prior Art Database

Mechanism to Persist Objects In a File Using Linked Fixed Size Slots

IP.com Disclosure Number: IPCOM000168520D
Original Publication Date: 2008-Mar-14
Included in the Prior Art Database: 2008-Mar-14
Document File: 3 page(s) / 280K

Publishing Venue

IBM

Abstract

Disclosed is a mechanism to store heterogeneous objects of different sizes in a File for simple persistence without using a full-fledged database. The data can be accessed at a granularity of a single object instance. There are custom solutions that can handle fixed size objects, same type of objects, or heterogenous objects with a drawback that any modification needs rewriting all the stored objects data into the file.The existing solutions are not generic and flexible. This disclosure addresses heterogenous objects, re-use of space of deleted objects, index recreation, and also provides a memory based cache for faster access of the objects.

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 57% of the total text.

Page 1 of 3

Mechanism to Persist Objects In a File Using Linked Fixed Size Slots

Names: Murali Vn Sappa

This disclosure claims that the object data can be serialized and stored in a file that is organized as fixed size slots that are linked. A pointer to the free slots is also maintained.

The size of the object to be persisted is not affected by the size of the fixed size slot the file is organized into.

The object can grow in size or decrease in size without affecting the rest of the objects stored in the file and without necessitating re-writing of all the objects into the file.

When an object is deleted that space can be reused without leaving holes in the file there by avoiding costly file compression from time to time.

The file that stores the objects is organized into a space with fixed size slots and a header as shown in the figure.

Each block of data contains "NextBlock" field that is used to create a chain of blocks for persisting an Object whose data occupies more than on slot.

The "NoOfItems" field in the block indicates how many bytes are occupied by the Object in this slot. The two examples below illustrate how these fields are used. For both the examples, consider a slot of size 512 byes, NextBlock Size = 4bytes, and NoOfItems size = 4 bytes.

eg.1. Object size = 223 bytes, Object is located at Slot1.

The data in the slot 1 will be

NextBlock = -1, indicating the object occupies only one slot

NoOfItems = 223, the size of the object

Data = First 223 bytes contain the object data

eg.2. Object sze = 600 bytes, Object is located in Slots 2 and 3.

Slot 2 Data will be

NextBlock = 3

NoOfItems = 512 - 4(NextBlockSize) -4(NoOfItemsSize) = 504

Data = First 512 bytes of the object data

Slot 3 Data will be

NextBlock = -1, indicating end of the chain

NoOfItmes = 600 - 504 = 96.

Data = Last 96 bytes of the Object.

Using the same logic, the object can occupy as many slots as needed.

When an object is deleted, or shrunk in size, the freed up slots are added to a FreeBlock chain. When a new object is added or an existing object grows in size, the space is allocated first from the free slots, and if needed the file is extended to add more slots. The FreeBlockStart and FreeBlockEnd fields in the Header part of the file point to this FreeBl...