Object Oriented Database Learning Center

Objectivity Home - Government - Objectivity/DB - Webinars - Download Software

Table of contents:

Dynamic Containers™: The Key To Superior Performance

Deployment Examples

Typical Data Access and Usage: In most OLTP database applications, data is usually used not one datum at a time but usually in bunches or sets that may vary in size. Several associated objects may be created or accessed in a very short time frame. An example would be a customer order with a dozen different items. Most of the items may be in stock and shipped immediately and hence the representative objects modified in a very short time frame as well.

The database designer is able to tailor the page size in Objectivity/DB to the size of the bunch of data that is usually created or modified. This means that a single page could be about the right size for all the items that are on a typical order. However, there is no reason to insist that the page can contain only one order and its items. It could be larger to accommodate several orders and their items together. This brings up the issues of concurrency and performance when it comes to creating and updating objects by multiple users since Objectivity/DB locks at the container level.

By varying the size of containers you can trade off concurrency versus performance as in the graph below.

An alternative architecture could provide locking on individual objects or pages. With object-level locking architectures, locks have to be requested and granted for each object regardless of the fact that they may be associated and therefore will be updated as a group. The associated objects may even be on the same page due to clustering but cannot benefit from page level locking. This puts a theoretical limit on throughput of object-level locking systems. In the graph above, an object-level locking architecture will be on the right side of the graph at line A where concurrency is high but throughput is low. Page-level locking architectures are much better in that a single lock will allow you to update many objects within one page. However, when you wish to update objects across many pages you get back to having to manage quite a few locks and therefore throughput will still plateau at some level. Line B in the graph above illustrates that page-level locking also dictates the concurrency and throughput that may be obtained. Containerlevel locking allows the designer to vary the size of individual containers and the number of objects within that container according to the application’s needs. By placing one object per container, object-level locking is available. By having minimally sized containers, a form of page-level locking is thus available. Finally, by having containers with multiple pages, you can maximize throughput by requesting only one lock. In reality, most objects are not standalone. They are usually associated with other objects which can benefit from being on the same page or container and thus can be locked at the same time. This is represented by the shaded elliptical area in the graph above. The designer can thus move within that area on the graph and achieve varying levels of concurrency and throughput within a single application.

The fact that containers can be created at a specific size by the applications to store specific objects means that you can lock varying amounts of data by varying the size of the container. With this flexibility, the designer can make a very small container to store few objects as well as large containers to store large numbers of objects. Furthermore, containers can both grow and shrink in size as required. This gives Objectivity/DB variable locking granularity within the same database.