Objectivity Technical Overview. Release 9

(1)

Objectivity Technical Overview

Release 9

(2)

Objectivity Technical Overview

Part Number: 9-OTO-1

Release 9

The information in this document is subject to change without notice. Objectivity, Inc. assumes no responsibility for any errors that may appear in this document.

Copyright 1993–2009 by Objectivity, Inc. All rights reserved. This document may not be copied, photocopied, reproduced, translated, or converted to any electronic or machine-readable form in whole or in part without prior written approval of Objectivity, Inc.

Objectivity and Objectivity/DB are registered trademarks of Objectivity, Inc.

Active Schema, Objectivity/DB Active Schema, Assist, Objectivity/Assist, ooAssistant, Objectivity/DB ooAssistant, Objectivity/DB Fault Tolerant Option, Objectivity/FTO,

Objectivity/DB Data Replication Option, Objectivity/DRO, Objectivity/DB High Availability, Objectivity/HA, Objectivity/DB Hot Failover, Objectivity/DB In-Process Lock Server, Objectivity/IPLS, Objectivity/DB Open File System, Objectivity/OFS,

Objectivity/DB Parallel Query Engine, Objectivity/PQE, Objectivity/DB Persistence Designer, Objectivity/DB Secure Framework, Objectivity/Secure, Objectivity/C++, Objectivity/C++ Data Definition Language, Objectivity/DDL, Objectivity/C++ Active Schema,

Objectivity/C++ Standard Template Library, Objectivity/C++ STL, Objectivity/C++ Spatial Index Framework, Objectivity/Spatial, Objectivity for Java, Objectivity/.NET, Objectivity/. NET for C#, Objectivity/Python, Objectivity/Smalltalk, Objectivity/SQL++,

Objectivity/SQL++ ODBC Driver, Objectivity/ODBC, Objectivity Event Notification Services, and Persistence Designer are trademarks of Objectivity, Inc.

Other trademarks and products are the property of their respective owners.

ODMG information in this document is based in whole or in part on material from The Object Database Standard: ODMG 2.0, edited by R.G.G. Cattell, and is reprinted with permission of Morgan Kaufmann Publishers. Copyright 1997 by Morgan Kaufmann Publishers.

The software and information contained herein are proprietary to, and comprise valuable trade secrets of, Objectivity, Inc., which intends to preserve as trade secrets such software and information. This software is furnished pursuant to a written license agreement and may be used, copied, transmitted, and stored only in accordance with the terms of such license and with the inclusion of the above copyright notice. This software and information or any other copies thereof may not be provided or otherwise made available to any other person.

RESTRICTED RIGHTS NOTICE: Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the Objectivity, Inc. license agreement and as provided in DFARS 227.7202-1(a) and 227.7202-3(a) (1998), and FAR 12.212, as applicable. Objectivity, Inc., 640 West California Avenue, Suite 210, Sunnyvale, CA 94086-3624.

(3)

3

Chapter 4

Distributed Database Architectures

37

Evolution of Client/Server 37 Distributed Database Architecture 39

Chapter 5

Objectivity/DB

43

Safe Object Reference Architecture 43 Storage for Exabytes of Interrelated Objects 43 Platform Interoperability 44

(4)

Location Independence of Objects 44 Accessing Objects 44 Locking 46 Transactions 46 Object Clustering 47 Object-Level Versioning 47

Chapter 6

Objectivity/DB High Availability

49

Partitioning a Federated Database 49 Replicating Databases 51 Objectivity/DB High Availability Scenarios 54

Chapter 7

Developing with Objectivity/C++

63

Development Process 63 Data Modeling in C++ 65 Developing Applications 67 Using C++ Class Libraries 73

Chapter 8

Developing with Objectivity for Java

77

Development Process 77 Data Modeling in Java 78 Developing Applications 81 Database Garbage Collection 87 Object and Class Migration 87

Chapter 9

Developing with Objectivity/Smalltalk

89

Development Process 89 Data Modeling in Smalltalk 90 Developing Applications 92 Using Smalltalk Class Libraries 95 Automatic Online Database Garbage Collection 95 Automatic Storage Management 96 Automatic Object and Class Migration 96

(5)

Objectivity Technical Overview 5

Chapter 10

Objectivity/SQL++

97

Using Objectivity/SQL++ 97 Objectivity/SQL++ Examples 100 Objectivity/SQL++ Extensions 101 Interactive SQL++ 103

Objectivity/SQL++ ODBC Driver 106

Chapter 11

Objectivity Solutions

107

Objectivity/DB Active Schema 107 Objectivity/DB Open File System 109 Objectivity/DB Parallel Query Engine 110 Objectivity/DB Secure Framework 113 Objectivity Event Notification Services 115

Chapter 12

Development and Administration Tools

119

Data Modeling and Application Development Tools 119 Administering Objectivity/DB 125

Appendix A Page Server Performance

129

Assumptions 130

Page Servers Are More Efficient Than Object Servers 131 Page Server Has Less Network Delay 132 Page Server Uses Less Network Bandwidth 132

Appendix B Standards Support

135

Objectivity Involvement in Standards Organizations 135 Technology Standards 136

Appendix C Migrating a C++ Application

137

The Original C++ Example 137 The Objectivity/C++ Application 144

(6)

Appendix D Migrating a Java Application

153

The Original Java Example 153 The Objectivity for Java Application 158

Appendix E Migrating a Smalltalk Application

165

The Original Smalltalk Example 165 The Objectivity/Smalltalk Application 170

Appendix F Resources Appendix

175

Publication Resources 175

Web Resources 176

(7)

7

1

Introduction

Database management for today’s high-end applications. Objectivity/DB is a distributed object database management system (ODBMS). As an ODBMS, Objectivity/DB is ideal for applications that require complex data models. As a distributed ODBMS, Objectivity/DB supports large numbers of users and provides high-performance access to large volumes of physically distributed data.

Objectivity/DB manages data transparently to high-end applications. Its distributed database architecture provides scalability as well as performance. This architecture supports a wide range of application architectures, including client/server, mixed-tier, and service-oriented.

Objectivity/DB integrates easily with application software. It allows you to directly store and manage objects through standard language interfaces—such as, C#/.NET, C++, Java, Python, Smalltalk, SQL and XML—using traditional programming techniques and tools.

Integrates into your existing environment. Objectivity/DB also integrates into existing computing environments. It supports complete interoperability across major hardware platforms and operating systems. Through its ANSI-standard SQL interface, you can leverage your SQL-programming knowledge to use popular client/server tools compliant with Microsoft’s Open Database Connectivity (ODBC) interface.

Why Use an ODBMS?

Relational database management systems (RDBMSs) have been in use for many years. These systems are well-suited for applications that use tabular data models. Typical RDBMS applications include billing and inventory tracking, where simple, fixed-length data is represented in table form. RDBMSs perform basic operations such as joins, projections, and selections in short transactions. These systems have served well for traditional online transaction processing (OLTP), accounting, and online entry applications requiring database control of textual and numerical data.

(8)

Introduction Why Use an ODBMS?

Some vendors in the RDBMS market added “objects” to their RDBMS engines and called them Object Relational DBMS (ORDBMS). These extensions to their engines include Extended Data Types (EDTs) and complex objects. However, the underlying mismatch between the object-oriented software and the database still exist, resulting in substantial performance penalties.

If you can solve the problem with an RDBMS without a lot of effort and also achieve the performance, throughput and scalability that you need then there's no compelling reason to use an ODBMS. However, if any of the following conditions are met then you should consider using Objectivity/DB:

■ Complex Relationships

If there are a lot of many-to-many relationships, tree structures or network (graph) structures.

■ Complex Data

If the data has multiple varying length components, particularly multi-dimensional arrays, arrays of structs or binary streams.

■ Distributed Databases

If the databases need to be geographically distributed, used in a detached mode or are accessed from a processor grid (or “farm”).

■ Multiple Languages or Platforms

If the system will use multiple languages and/or platforms.

■ Repetitive Use of Large Working Sets of Objects

If your application performs many successive transactions on the same “working set” of objects.

■ Massive Scalability

If you have very large amounts (Exabytes) of data, databases at large numbers of sites or a very large numbers of clients.

■ Expensive Mapping Layer

If you are expending effort on decomposing objects to fit into rows and columns you will be able save time by eliminating the mapping layer. You will no longer need to do ad hoc queries to locate individual objects by storing binary data as BLOBs (Binary Large Objects) or construct artificial JOIN tables to express many-to-many, tree and network relationships.

(9)

Introduction Why Use an ODBMS?

Many applications require storage of complex data.Many of today’s applications are more sophisticated than traditional OLTP. These new

applications cover a broad domain, including authoring systems, bioinformatics, collaborative engineering, finance, groupware, intelligence, logistics,

manufacturing, multimedia, process control, and telecommunications. These applications require additional data management capabilities not available from RDBMSs and ORDBMSs, such as complex data models, high-performance object management, relationship navigation, and transaction models for both long and short transactions.

Combines the power of object technology with traditional DBMS features.

Objectivity/DB meets the feature and performance requirements for

mission-critical applications by combining the flexibility of object technology with the data management capability of RDBMSs and ORDBMSs. It provides high-performance data management without sacrificing integrity or multiuser concurrency.

Like RDBMSs and ORDBMSs, Objectivity/DB supports the ACID properties of DBMSs. These properties are Atomicity, Consistency, Isolation, and Durability. Atomicity means that each transaction is executed completely or not at all. Consistency means that transactions are serializable, allowing the database to remain in a consistent state. Isolation indicates that the operations within one transaction are not affected by other transactions. This is accomplished through locking mechanisms. Durability means that committed data persists despite machine failures.

(10)

Introduction Standards

ODBMSs differ from RDBMSs and ORDBMSs in several ways. Some of the characteristics of DBMSs are listed in Table 1-1. If your database application requires one or more of the ODBMS characteristics, Objectivity/DB may be the right DBMS choice. Even if your application does not have these requirements, but you want the benefits of distributed data, Objectivity/DB may provide the best solution.

Table 1-1:

Database Requirements ODBMSs RDBMSs ORDBMSs

ACID properties Yes Yes Yes Data model complexity High Low Variable

a. Varies with different vendors

a

User-defined data types Yes Not yet Yes Versioning Yes No No Application development Object-oriented 4GL 4GL, 3GL Polymorphism Yes No Maybe Inheritance Yes No Maybe

ODBMS, RDBMS, and ORDBMS Comparison

Standards

Over the past several years, computer users have demanded open systems across all aspects of software technology, from operating systems to languages to databases. Standards organizations such as the Object Data Management Group (ODMG) were established to ensure that present and future ODBMS systems will support the open environments users need. As a founding member of ODMG, Objectivity played a leadership role in helping develop these standards.

Objectivity played a key role in standards organizations. Objectivity has played a key role in the Object Management Group (OMG), actively participating in the CORBA Persistent Object Service standard, and supporting ANSI

standards for C++ and SQL. Objectivity is also active in the formal and informal processes for extending the Java language and defining database access

(11)

Introduction Typical Applications

Typical Applications

Objectivity/DB is effectively employed as a database storage solution in a variety of enterprises. This section describes some typical areas of deployment.

Bioinformatics Applications. Objectivity/DB is appropriate for a variety of bioinformatics applications. Objectivity/DB’s ability to store and process complex structures (collections, trees and networks), images and data streams makes it an ideal database for applications such as:

■ Comparing and visualizing nucleotide or protein sequences

■ Analyzing and visualizing phylogenetic trees and 3D protein structures

■ Protein structure prediction

■ Primer design and analysis

■ Strategic recombinant design

■ Computer-Aided Molecular Design

Data-Intensive Sciences Applications. Objectivity/DB is used in a wide range of data-intensive science applications. Objectivity/DB is typically implemented in the following areas:

■ Modeling and simulation

❐ Experiment design and simulation

❐ Process simulations

❐ Macro-nano Earth Sciences and bioinformatics models

■ Analyzing and archiving

❐ Equipment calibration records

❐ High speed data ingest to a persistent store

❐ Experiment results management

■ Relationship hunting

❐ Data correlation for experiments in the astrophysical, biological, chemical, fusion, HEP and other domains

Government Applications. Objectivity/DB technology is used in many different government applications. Government customers typically implement Objectivity/DB in the following areas:

■ C4ISR and data fusion

■ High Performance computing

❐ Simulation & virtual reality assisted training

❐ Correlation and analysis

❐ Video/Audio/ELINT/Telemedicine streaming and processing

(12)

Introduction About Objectivity, Inc. Manufacturing and Process Control Applications. Objectivity/DB is typically used by manufacturing and process control administrators to manage and store complex data. Some typical manufacturing and process control applications of Objectivity/DB are in the areas of:

■ Designing, modeling and simulating

❐ Process and plant design

❐ Process control simulations

❐ Virtual reality assisted training

■ Monitoring, analyzing and responding

❐ Instrumentation systems

❐ Statistical process control

❐ Quality assurance data collection and archiving

❐ Plant management

❐ Manufacturing planning and logistics

■ Relationship hunting

❐ Long term fault/anomaly correlation

❐ Downtime analysis

Telecom Applications. Objectivity has extensive experience in the deployment of distributed ODBMS technology in advanced telecommunications systems. Objectivity/DB is in use within wireline, wireless and cable systems.

Objectivity/DB is employed in many telecommunications applications. These systems have been implemented either by equipment manufacturers and software tool vendors or by systems integrators in partnership with service providers. Typical deployments include:

■ Intelligent networking

■ Network management and element management systems

■ Telecommunications software development tools

■ Multimedia repositories

About Objectivity, Inc.

Objectivity is an industry leader. Objectivity, Inc. is the leading provider of distributed, scalable object databases with unrivaled support for mixed-language development and mixed hardware.

World-wide sales support and consulting. Objectivity provides high-quality technical support and consulting to guarantee customer success with the

(13)

Introduction About Objectivity, Inc.

development of data models and system architecture for optimal performance and reliability.

Expert engineers with experience in DBMSs and application development comprise Objectivity’s customer support and critical response teams. In international markets, Objectivity works with experienced distribution and consulting firms to provide local support to customers.

For the location of a sales office in your area, visit the Objectivity Web site (www. objectivity.com/).

(14)

(15)

15

2

Product Family Overview

Objectivity/DB is a distributed ODBMS. It is designed for mission-critical and production environments and offers high performance, virtually unlimited scalability, and interoperability across all major platforms and operating systems. The Objectivity software product family is shown in Figure 2-1.

Objectivity Professional Services

HPSS and Security Frameworks Parallel Query Engine (PQE)

Application Programming Interfaces

Objectivity/DB and Developer Tools Assist (Eclipse IDE) Open-File System (OFS)

IPLS Active Schema High Availability

Figure 2-1 Objectivity Product Family

Objectivity/DB Product Group

The core database product is Objectivity/DB. It consists of shared libraries, several servers, and a comprehensive set of administrative tools. The shared libraries and servers provide storage and retrieval of local and distributed data, and ensure data integrity through transaction management. The administrative tools make administration of Objectivity/DB databases easy and flexible.

(16)

Product Family Overview Distributed Database Architecture

Other members of the Objectivity/DB product group include Objectivity/DB High Availability, Objectivity/DB In-Process Lock Server, Objectivity/DB Parallel Query Engine and several framework products.

Distributed Database Architecture

At the heart of Objectivity/DB is a unique, distributed database architecture. Because of this architecture, Objectivity/DB can deliver consistent high performance even as the amount of stored data and number of users grows. Objectivity/DB databases can support Exabytes of data spread physically across a corporate enterprise.

Objectivity/DB offers the most advanced distributed database architecture available today. This architecture distributes processing and data storage tasks transparently across machines, thereby allowing applications to benefit from high-performance local processing through modern networks. This architecture also provides scalability and high availability to distributed data.

Objectivity/DB is partially grid-enabled. Future releases of Objectivity/DB will virtualize communications with processes and the placement of files.

Shared Libraries and Remote Servers

Figure 2-2 shows Objectivity/DB’s distributed architecture: distributed data and multiple servers. Instead of a traditional, centralized database server,

Objectivity/DB provides a client-side shared library and several types of specialized server processes—lockservers, dataservers, and queryservers.

■ Lock servers grant permissions (locks) to an application seeking to access data.

■ Data servers deliver data from storage on disk to application memory. The shared library, which is linked to the application, acts as a data server by obtaining data directly from the local file system. The shared library can also contact separate data-server processes on local or remote machines. A remote data server can be either Objectivity/DB’s advanced multithreaded server (AMS) or an industry standard file server. See Chapter 4, “Distributed Database Architectures,” for more information.

■ Query servers improve the performance of certain queries.

Query servers are provided with Objectivity/DB Parallel Query Engine. See Chapter 11, “Objectivity Solutions,” for more information.

(17)

Application Objectivity Kernel Process Lock Server Application Objectivity Kernel Process Data Server

AMS Data ServerAMS

Host 1 Host 2 Host 3

Query Server Local

Filesystem

Product Family Overview Distributed Database Architecture

Figure 2-2 Distributed Data and Multiple Servers

High-Performance Page-Server Architecture

Objectivity/DB remote data servers use a page-server architecture to provide optimal performance over a wide range of work loads. Page servers typically outperform object-server architectures by providing significantly higher transfer rates. Objectivity/DB adds cross-transaction caching for an added performance boost for applications. Objectivity/DB data servers offer the highest possible performance for a wide range of multiuser applications. Flexible locking mechanisms, including multiple readers, one writer (MROW) for non-blocking writes, allow Objectivity/DB to achieve high concurrency.

Two implementations of remote data servers are available. The first is Objectivity/DB’s advanced multithreaded server (AMS). AMS provides

multithreaded fast access to data and significantly improves performance when updating data stored in remote databases. Remote data servers can also be provided by industry standard file servers offered by companies such as EMC, Hewlett Packard, IBM, Silicon Graphics and Sun Microsystems.

(18)

Product Family Overview Development and Administration Tools

Multiple, Distributed I/O Servers

As was shown in Figure 2-2, Objectivity/DB enables you to distribute data transparently across multiple machines in a network. As a result, multiple data servers can share the processing load for server operations. This eliminates the processing bottleneck that may occur when data is stored on a single machine. Because the physical location of objects is transparent to Objectivity/DB applications, you can locate and relocate objects on any machine without changing your application code.

Parallel I/O and Locking for Multiple Client Processes

To further improve performance, Objectivity/DB data server processes execute I/O requests from multiple application processes in parallel, even if the requested data resides on the same machine. Each application process can perform its I/O and lock operations without waiting for a server process to complete an I/O or lock request from another application.

Development and Administration Tools

Objectivity/DB provides a graphical tool, Objectivity/Assist, to help you develop databases and database applications, and browse and query the data. Objectivity/Assist uses the popular open-source Eclipse Platform.

In addition to development tools, Objectivity/DB provides a set of

administration tools and APIs to help you successfully administer and deploy your databases and applications to end users. These tools include database configuration, online incremental backup and restore, online object relocation, recovery tools, and database compaction, among others.

For additional information, see Chapter 12, “Development and Administration Tools.”

Safe Object Reference Architecture

Consistent with ODMG standards, Objectivity/DB accesses objects through indirect handles or object references instead of direct pointers. Through handles and object references, Objectivity/DB guarantees object integrity, even if the object is moved to another location in memory after the transaction is completed.

(19)

Product Family Overview Interoperability

Interoperability

Objectivity/DB provides complete and transparent interoperability (platform heterogeneity) among leading hardware architectures and operating systems, allowing you to distribute or move databases among different machines. This support lets you use your existing hardware investment, and gives you flexibility in choosing future hardware. Objectivity/DB also provides interoperability between supported languages, such as C++ and Java, within the constraints of those languages.

Application-Side Caching

With Objectivity/DB, an object is brought intact directly from disk the first time it is needed. The object is then stored for easy access in the cache where the application process is running. Since navigation between cached objects occurs at in-memory speeds, this application-side caching of objects further improves performance. As a result, object navigation operations are significantly faster with Objectivity/DB than with RDBMSs and ODBMSs that only perform caching in centralized servers.

High-Performance Concurrency Support

Many complex applications today are designed for workgroup environments. These applications unite computing and communications, allowing people to collaborate on complex problems through workgroups. Applications of this kind often use object-oriented technology, a variety of server configurations

(client/server, mixed-tier, and so on), and elegant graphical user interfaces. In addition to text, users share and operate on complex object types such as images, three-dimensional graphics, and sound. Objectivity/DB provides concurrency support through locking, transaction semantics, and the ability to support multiple readers, one writer (MROW) on the same data at the same time.

Data Modeling Features

Objectivity/DB supports several data modeling mechanisms consistent with the various supported programming languages:

■ For C++ applications, you design your data model using the Data Definition Language (DDL). The DDL is standard C++ with a few extensions

supporting Objectivity/DB features such as object relationships.

■ For Java or Python applications, you define classes that take advantage of the capabilities of Objectivity/DB.

(20)

Product Family Overview Data Modeling Features ■ For Smalltalk applications, you use standard VisualWorks classes and

Objectivity/DB classes to develop your data model.

■ For SQL applications, Objectivity/DB automatically generates an equivalent SQL data definition for all object classes, making it easier to integrate legacy applications and ODBC tools.

Layered Hierarchy for Object Storage

As shown in Figure 2-3, Objectivity/DB provides logical storage through

persistentobjects, databases, and federated databases. These objects continue to exist after your application terminates, and can be shared among applications, with locking managed by Objectivity/DB.

The highest level of storage is the federated database. Each federated database logically contains one or more databases. It also contains the data model (or

schema) and a catalog of all databases that comprise the federation. Each database contains persistent objects. Objectivity/DB also supports the clustering of objects within containers to enhance performance. See “Object Clustering” on page 47. An object can consist of object-oriented language-specific constructs, with the addition of variable-size arrays, relationships to other objects, references to other objects, and type constraints. Your application can create and delete persistent objects dynamically (except for the federated database itself).

Multi-File Databases

A database is physically represented by a database file, which contains:

■ The database’s default container

■ Zero or more containers created by applications

■ A catalog of the containers belonging to the database

Database files are typically used to distribute related containers and their basic objects to different physical locations in your network.

For a very large database (VLDB), the database’s file size can become too large to manage easily. To solve this problem, an application can choose to store selected

external containers in their own separate container files. External containers enable the creation of multi-file databases.

(21)

Container Container Database Database Container Federated Database

Product Family Overview Data Modeling Features

Figure 2-3 Layered Storage Within a Federated Database

Complex Interrelationships

In your data model, you can design objects with complex interrelationships that Objectivity/DB maintains automatically. These relationships can be

unidirectional or bidirectional. For C++ applications, these relationships are called associations.

Composite Objects

Relationships also allow you to create composite objects consisting of groups of interrelated objects. These objects can behave as one object for locking and delete operations.

Advanced Schema Evolution Capabilities

Objectivity/DB allows you to easily change your data model (schema) as the needs of your applications and users change. This feature, known as schema evolution, allows you to change classes, their contents, and their inheritance. Supported operations include: renaming and deleting a class; adding, deleting, and changing data members, associations, and object references; and adding, deleting, and changing base classes, among many others.

For many operations, Objectivity/DB automates the conversion process for existing objects changed by schema evolution. For more complex changes,

(22)

Product Family Overview Objectivity/DB High Availability

Objectivity/DB provides programming interfaces that support the data conversion process.

Along with Objectivity’s patented schema evolution,

Objectivity/DB Active Schema allows an application to completely reconfigure itself to accommodate changing conditions, without taking the application or database offline. Objectivity/DB Active Schema also guarantees the integrity of the resulting database schema through the use of a unique Schema Engine. See Chapter 11, “Objectivity Solutions,” for more information. Active Schema is available in the C++ and Java bindings.

Objectivity/DB High Availability

Objectivity/DB High Availability is an option that supports fault tolerance and improved performance for large database deployments. This product improves data availability after network failures by distributing lock management and replicating the database schema and catalog to multiple locations in a network. Using Objectivity/DB High Availability, database administrators can divide a federated database into autonomous partitions. Partitioning replicates metadata in each partition so that each partition is self-sufficient and insulated from network and other system failures. Objectivity/DB High Availability is transparent to deployed applications.

Objectivity/DB High Availability improves data availability and read

performance by replicating a subset of data in multiple locations in a network. Replicating data can also eliminate the danger of a single point of failure to the database.

Objectivity/DB Parallel Query Engine

Objectivity/DB Parallel Query Engine enables you to perform fast queries over very large numbers of objects in a very large database (VLDB). This product also supports more complex search or filtering algorithms, exploits the use of

distributed resources (for example, many cheaper server hosts instead of a very large central server), and will eventually support searches of non-Objectivity DBMSs.

You typically use Objectivity/PQE when you need to scan large amounts of data in order to find comparatively few objects satisfying a predicate condition. Objectivity/PQE speeds up such a search by employing concurrent

multithreaded queryservers to scan different portions of the data in parallel. When each query-server thread searches a set of databases, it reads their data into its own cache, instead of into the cache of the querying application. This can significantly reduce network traffic when the databases are on remote hosts.

(23)

Product Family Overview Objectivity/DB In-Process Lock Server

Objectivity/PQE has modifiable components for determining the target

containers and databases, controlling the local thread pool, and filtering objects before they are returned to the client. For example, to optimize the query according to how you’ve organized your data, you can customize the search so that every query-server thread scans selected containers of selected databases.

Objectivity/DB In-Process Lock Server

In addition to a standalone lock server process, Objectivity offers an in-process lock server (IPLS), which can be linked to an Objectivity application. From the perspective of other distributed clients, the Objectivity/IPLS performs the same way as a regular lock server. However, when most of the persistent operations are coming from a single multithreaded process then the inter-process

communication is greatly reduced, and greater performance can result.

Objectivity/DB Open File System

Objectivity/DB Open File System (Objectivity/OFS) provides a customizable interface between Objectivity’s distributed, scalable database and high-end storage solutions. This capability is used to provide an interface to High

Performance Storage Systems (HPSS) and can also be used to create an interface to other Hierarchical Storage Manager (HSM) systems. Objectivity/DB has been run successfully with the SGI InfiniteStorage Shared Filesystem CXFS for Storage Area Networks (SANs).

Objectivity/DB data files can be protected using standard operating system security mechanisms. Because these mechanisms may be inadequate for some applications, it is possible to call a Generalized Security Architecture hook from within the Objectivity/OFS layer. The functionality invoked by the hooks can interact with the appropriate security mechanisms in use at a particular site. This makes it feasible to have a federation with partitions spread across multiple sites, each imposing their own security policies. Kerberos authentication is used by default, but the client to AMS protocol can be modified to use other mechanisms. SQL++ users can also use the standard SQL GRANT and REVOKE mechanisms.

Powerful Object-Oriented Development

The Objectivity/DB product family is designed for mission-critical application development and deployment. It supports object-oriented design and

implementation through industry-standard languages.

With Objectivity/DB, you can develop object-oriented applications using standard languages, compilers and development tools you already know. There is no need to use non-standard compilers, debuggers, or tools.

(24)

Product Family Overview C++ Support

Objectivity/DB is fully compatible with standard integrated design environments. Because of this compatibility, you can choose among many popular development environments when developing Objectivity/DB applications.

C++ Support

Objectivity/C++ provides a programming interface that is transparent to native C++ compilers. With Objectivity/C++, you can add object database features to your applications using standard C++ functionality, including single and multiple inheritance and templates.

C# and .NET Support

Objectivity enables complete support for the .NET platform, thereby enabling the development of massively parallel database applications.

Objectivity has made its high performance persistence engine a managed runtime that is callable from any language that compiles to IL (Intermediate Language). Therefore, persistent objects can now exist in all of the Microsoft . NET supported languages such as C#, VB.NET C++ and J#, as well as

non-Microsoft languages that support the .NET Common Language Runtime, including Ruby, LISP, and FORTAN.

Java Support

Objectivity provides full support for Java with a language binding compliant with the ODMG standard. Objectivity’s unique “single process model”

architecture for Java-based applications provides the highest performing solution in the industry, because the application program and the Java Virtual Machine run in the same process, ensuring that valuable processing cycles are not wasted on constant process switching. Along with full support for Java multithreading, Objectivity for Java represents a truly industrial-strength solution for complex computing needs.

A Java 2 Platform Enterprise Edition (J2EE) Connection Architecture resource adapter allows Objectivity for Java to interface with any application server supporting JCA. Rather than requiring manual vendor-specific connection management coding, the JCA feature uses the Common Client Interface (CCI) to manage connections to an Enterprise Information System. The resource adapter has been tested with the BEA WebLogic and IBM WebSphere application servers, making it easier to incorporate Objectivity for Java into systems that use a Service-Oriented Architecture.

(25)

Product Family Overview Python Support

Python Support

The Objectivity/Python binding provides an easy to use, dynamic, scriptable interface to Objectivity/DB. Objectivity/Python can be used to develop new applications or to link together existing applications.

Python is a high-level interpreted language that provides an excellent interface to the operating system and network. Easy to script, Python is ideal for database administration, QA testing, and the development of analysis programs.

Smalltalk Support

With Objectivity/Smalltalk, you use VisualWorks from Cincom to develop applications. You can also use the ENVY/Developer from Object Technology International for multiuser development environments. As is standard in Smalltalk, with Objectivity/Smalltalk you benefit from automatic garbage collection and object evolution.

SQL++ Support

The Objectivity/SQL++ product is an ANSI SQL-92 standard SQL engine you can use to access and manipulate objects stored in Objectivity/DB databases. Like SQL, Objectivity/SQL++ allows you to create tables, delete tables, and update objects. It provides an object relational interface to an Objectivity/DB federation.

XML Support

XML is an increasingly important standard for facilitating data transfer between business systems. The Objectivity XML Interface tools support:

■ Exporting objects from the latest version of Objectivity/DB in XML format

■ Importing XML formatted data into Objectivity/DB

Namespace Support

Objectivity/DB provides full support for namespaces (Java packages) for

persistence-capable classes. For example, C++ persistence-capable classes may be defined in a namespace, and namespace qualifiers may be used to refer to them. Similarly, Java persistence-capable classes may be defined in a package, and a package may be used to refer to them. Objectivity/DB Active Schema provides a namespace API for iteration and scope lookup.

(26)

Product Family Overview Language Interoperability

Language Interoperability

Persistent objects can be created by applications written in any of the

Objectivity/DB application program interfaces. Once created, persistent objects can be accessed by applications using the same API or by applications using any other Objectivity/DB API, provided the corresponding class definitions in all applications are compatible with schemas of the shared federated database. This allows for more flexibility to select the language best suited to the application development environment.

Scalable Collections

Objectivity/DB supports language-independent persistent collections that are scalable to hundreds of millions of objects. For example, a collection created in C++ would be accessible in Java or Smalltalk, and vice versa. The scalable collections are patterned on JDK 1.5 specifications, and the Objectivity for Java implementation uses the Java 2 interfaces.

Objectivity/C++ Product Group

Objectivity/DB supports industry-standard object-oriented programming languages for developing database schemas and applications. You use these languages to define the objects to be stored in your database and to create applications that access and manipulate the stored objects. The Objectivity/C++ group consists of Objectivity/C++ and Objectivity/C++ Data Definition

Language.

Objectivity/C++ provides many features for implementing C++ applications. Table 2-1 briefly summarizes some of these features.

Table 2-1: Objectivity/C++ Development Features

Feature Description

Creation and deletion functions

Create and delete objects.

Association functions Set, delete, and navigate associations (relationships) between objects.

(27)

Product Family Overview Objectivity/C++ Product Group

Access functions ■ Name and look up objects.

■ Use map dictionaries to look up objects based on keyed values.

■ Define index values for objects and use indexing functions to access objects across containers, databases, and federated databases.

■ Traverse objects using iterators that select objects based on object type, name, an indexed value, containment, association, or user-defined selection criteria.

■ Query and access objects using the Objectivity/SQL++ interface.

Version functions ■ Create versions of objects.

■ Track version genealogy.

■ Locate any version at any time.

■ Specify any object as the default version.

Copy and move functions Copy or move objects from one container to another. Object and class migration

function

Evolve existing classes and create new ones.

Class libraries for C++ applications

■ Variable-size array classes for creating and manipulating persistent and transient arrays that can vary in size dynamically.

■ String classes for creating and manipulating variable and fixed-size strings.

■ Map dictionary classes for creating dynamic structures that map user-defined keys to objects.

■ Scalable collection classes for bags, sets, lists, trees and other common groupings of objects.

Table 2-1: Objectivity/C++ Development Features (Continued)

(28)

Product Family Overview Objectivity for Java Product Group

Objectivity for Java Product Group

Objectivity provides full support for Java with a language binding compliant with the latest ODMG standards, thereby enabling the rapid development and deployment of complex, mission-critical applications.

Objectivity for Java provides many features for implementing Java applications.

Table 2-2: Objectivity for Java Development Features

Feature Description

Full support for Java Compliant with Java 2. “Single process model”

architecture

The application program and the Java Virtual Machine run in the same process, ensuring that processing cycles are not wasted on constant process switching.

Flexible persistence model Classes can be made persistence-capable through inheritance or by an interface; full control of when and how an object is stored in the database is provided.

Java multithreading support Transactions can share threads or have a thread dedicated to a particular transaction, providing an industrial-strength solution for complex computing needs.

ADE support Complete support and compatibility with leading application development environments (ADEs) including debuggers.

Platform portability Investment in application development is preserved because Objectivity for Java delivers true portability across a wide variety of hardware platforms.

(29)

Product Family Overview Objectivity/Smalltalk Product Group

Objectivity/Smalltalk Product Group

The Objectivity/Smalltalk product group extends standard VisualWorks Smalltalk from Cincom for developing Objectivity/DB applications.

Objectivity/Smalltalk provides many classes and methods you can use when developing Smalltalk database applications. Table 2-3 briefly summarizes some features these classes and methods provide.

Table 2-3: Objectivity/Smalltalk Development Features

Feature Description

Creation and deletion functions

Implicit feature of Smalltalk.

Association (relation) functions

Set, delete, and navigate relations between objects.

Access functions ■Use standard Smalltalk dictionaries to lookup objects based on keyed values.

■Traverse objects using iterators that select objects based on relations.

Version functions ■Create versions of objects.

■Track version genealogy.

■Locate any version at any time.

■Specify any object as the default version. Class libraries for

Smalltalk applications

Supports Smalltalk class libraries from Cincom.

Automatic online database garbage collection

Supports standard automatic garbage collection of transient and persistent objects.

Automatic storage management features

Provides automatic mechanisms for locking, tracking, and clustering objects.

Automatic object and class migration

Supports automatic migration of objects and classes as in standard Smalltalk.

(30)

Product Family Overview Objectivity/SQL++ Product Group

Objectivity/SQL++ Product Group

With Objectivity/SQL++, applications and SQL-compliant tools can use

ANSI-standard SQL to create, access, manipulate, and delete objects stored in an Objectivity/DB database. Objectivity/SQL++ provides full support of

ANSI SQL 1992.

Object Extensions

In addition to supporting standard ANSI SQL, Objectivity/SQL++ supports object extensions to SQL. These extensions support inheritance and allow you to access data members, associations, object references, and non-SQL types such as arrays. One use for this feature is to use associations and object references as implicitly-defined indexes for SQL join operations.

Stored Procedures and Triggers

Objectivity/SQL++ supports stored procedures. This feature lets you call C++ and C procedures directly from SQL. You can use built-in stored procedures, or build your own using a standard set of data types, data structures, macros, and member functions.

Objectivity/SQL++ also supports triggers. Triggers are C++ procedures that are called whenever SQL performs a database modification. You can implement and register your own triggers for SQL INSERT, UPDATE (pre-update and

post-update), and DELETE operations.

User-Defined Security

Through Objectivity/SQL++, you can control access to your database by implementing security based on a user name, a password, or both.

ODBC Tool Support

Objectivity/SQL++ provides an Objectivity/SQL++ ODBC Driver (level 3), which is an SQL programming interface for end user applications. It allows client/server tools that are based on the Microsoft Open Database Connectivity (ODBC) interface to access and manipulate Objectivity/DB objects. These off-the-shelf tools are available from numerous vendors and include graphical user interface builders, form entry systems, report generators, and ad hoc query tools. Any tool that is ODBC-compliant can access data in an Objectivity/DB database.

(31)

31

3

Data Modeling

This chapter describes Objectivity/DB data modeling common to all Objectivity/DB applications.

Data modeling is the key factor in choosing any DBMS. Data modeling with Objectivity/DB is identical to modeling data in non-database applications; that is, you decide which objects you want to use in your application and how those objects behave and interact. With Objectivity/DB, you can also specify objects you want to store in the database and relationships between objects. The data model you define for your database and its applications is called the schema.

Complex Data Models

Today’s complex business applications require complex data models. While RDBMSs continue to offer good solutions for data models of low complexity, ODBMSs are well suited for implementing highly complex data models. Some of the most complex models include acyclic graph and network data models, such as those used for bill-of-material modeling and network topologies.

For complex data models, RDBMSs fall short in terms of performance.

Representing complex data in an RDBMS requires numerous tables that must be joined together to represent a desired data set. However, these join operations are inefficient, particularly when joining three or more tables.

To work around this inefficiency, RDBMS application developers instead

implement simpler database data models and increase the complexity of the data model used by applications, as illustrated in Figure 3-1. Where possible,

developers reduce the complexity of the operations used against the relational database, and assemble the desired complex data within the application using mapping code, which can amount to between 20 and 45 percent of typical applications, and which can be a considerable update and maintenance burden.

(32)

Data Modeling Efficient Navigation Between Objects

For example, rather than using a series of join operations for a query, developers write code that performs a sequence of queries on individual tables, using the result of each query as a filter for the next until the desired result is obtained.

Efficient Navigation Between Objects

Because in ODBMSs the data model is the same in the application and the database, the application can make use of navigation between objects. This is more efficient and provides better performance than when RDBMSs search through indexes and table joins.

Data Model Maps to Application and Database

ODBMSs are ideal for data models of high complexity. With Objectivity/DB, the data model you design is tightly integrated with the applications you develop. As shown in Figure 3-1, there is a natural mapping of the data model to both the application and the database. There is no need to translate between application objects and those stored in the database because the application and database share the same data model. This inherent mapping of data on disk to that used in the application significantly improves performance because the data does not have to be constructed from simpler parts.

Application

Database

Mapping Code

Mapping of Data Model

By RDBMS By ODBMS

Application

Database

(33)

Data Modeling Object Relationships

Object Relationships

Objectivity/DB also provides a mechanism for defining relationships between objects. This mechanism provides higher-level capabilities than simple pointers for modeling and managing relationships between objects. Relationships are maintained automatically by Objectivity/DB. Objectivity/DB supports unidirectional and bidirectional relationships, relationship cardinality, and the use of relationships to create composite objects.

Relationships Are Unidirectional or Bidirectional

A unidirectional relationship is one in which only one class defines a relationship link to another class. A relationship between two objects in which each object’s class has a relationship link to the other class is called a bidirectional

relationship. Bidirectional relationships allow you to locate an associated object from either of the two associated objects. An important advantage of using bidirectional relationships in your data model is that Objectivity/DB maintains the referential integrity of your object relationships, and therefore contributes to the robustness of your application.

Relationship Cardinality

A relationship has two ends. A relationship’s cardinality is the number of objects on one side of a relationship that may be related with objects on the other side. For example, in Figure 3-2, there is a one-to-many relationship between a library object and book objects. Objectivity/DB relationships support four categories of cardinality:

1:1 One-to-one 1:m One-to-many n:1 Many-to-one n:m Many-to-many

(34)

Loan dueDate Library name Book title hasBook fromLibrary hasLoans allBooks fromLibrary inLoan author subject isbn address phone

Data Modeling Relationships in Composite Objects

Figure 3-2 Data Modeling With Relationships

Relationships in Composite Objects

You can use relationships to create composite objects, which group interrelated objects so that they behave as one object for propagating operations such as deletion and locking. Any type of object can be used in a composite object, and an object can be part of any number of composite objects. When you define relationships between your classes, you can specify which operations should propagate, and the direction of propagation. As shown in Figure 3-3, a book can be a composite object combining chapters and pages. When you delete the book, you also delete its chapters and pages.

P P

Book

Chapters

Pages

Figure 3-3 Composite Object

Propagation along a relationship is optional. That is, an operation works on a single object, unless the operation is explicitly issued with a propagate attribute. If the attribute is present, the operation applied to the target object will propagate to associated objects.

(35)

Data Modeling Evolution of Data Models and Object Conversion

Evolution of Data Models and Object Conversion

Over time, you will make changes to your applications to incorporate new features. Accordingly, you will need to make comparable changes to the data model your applications use. This process is known as schema evolution.

Data Models and Objects Can Evolve With Your Needs

As shown in Figure 3-4, Objectivity/DB allows you to evolve a data model as the needs of your applications and users change. Through schema evolution, you can go beyond simply adding new classes to your schema. You can also make changes to existing classes, their contents, and their inheritance. For example, you can use schema evolution to:

■ Rename and delete classes.

■ Add, delete, and change data members, associations, and object references.

■ Add, delete, and change base classes.

If this is combined with the performance improvements in new hardware happening every 6 to 12 months, then Objectivity/DB can leverage processor and I/O subsystem improvements more easily.

Existing Schema Evolved Schema

Schema Evolution Process Before Schema Evolution After Schema Evolution Figure 3-4 Schema Evolution

(36)

Data Modeling Automatic and User-Defined Object Conversion Options

Automatic and User-Defined Object Conversion Options

Objectivity/DB automates the conversion process for existing objects that have been changed by schema evolution. This object conversion capability is especially important in production environments where an upgrade to a new software version usually requires that existing objects be converted to the new data model.

Control Timing and Granularity of Conversion

The object conversion process is shown in Figure 3-5. You can choose the timing of object conversion as either deferred, on-demand, or immediate. A deferred conversion mode converts objects the first time they are accessed. An on-demand mode invokes object conversion from within an application to convert objects at a specified granularity. The immediate mode implies that a single-use upgrade application will be used to help convert all objects in a federated database within a single transaction. This upgrade application only is necessary for replacing a base class or deleting a class that has inherited references, and is supported by special upgrade functions.

These three conversion modes give organizations the freedom to choose the type of schema evolution timing that is best for them, depending on their application and operational requirements.

For any of these conversion modes, you can also provide conversion functions to calculate values of new data based on old values during the conversion process.

Evolved Schema Evolved Schema

Automatic Before Object Conversion After Object Conversion Conversion Upgrade Application

(37)

37

4

Distributed Database Architectures

Objectivity/DB delivers consistent high performance for database applications as the number of users, data servers, and data volume increases. It provides much of this performance because of its distributed architecture, which helps eliminate processing bottlenecks that affect databases with centralized architectures, including RDBMSs and most ODBMSs.

Evolution of Client/Server

As shown in Figure 4-1, database architectures have evolved from an

asymmetric, server-dominant design to a design that puts increasing processing on client machines. Initially, one server handled most of the processing tasks for one database application.

(38)

Based on a source from the Gartner Group CLIENT

Presentation Presentation Presentation Presentation

Application Function Application Function Application Function Application Function Application Function Data Management Data Management Data Management Data Management Data Management SERVER

Distributed Database Architectures Server-Dominant Models Created Bottlenecks

Figure 4-1 Client/Server Evolution

Server-Dominant Models Created Bottlenecks

Early database management systems were developed during the mainframe era, when a single mainframe served hundreds of terminals. Mainframe servers managed applications, I/O processing, database operations, and terminal display services. This architecture was adopted by RDBMSs and proliferated with the introduction of minicomputers.

When PCs became available, they replaced the terminals used in database configurations. Each PC had only 1/100th of the computational and I/O power of a mainframe, but this was enough to locally run graphical user interface (GUI) presentation services. This distribution of GUI services enabled mainframes to focus on number-crunching and I/O operations, including centralized database services.

As the power of PCs increased, more and more application functionality was moved to the client. This transition was limited by the traditional data server, which remained centralized and monolithic. To take further advantage of the inexpensive power of PC microprocessors, hardware manufacturers moved from

(39)

Distributed Database Architectures Distributed Database Architecture

a single microprocessor design to multiple parallel processors. RDBMSs followed with products that tried to capitalize on the speed of parallel processing, but were still limited by the centralized data server design of the past.

Centralized RDBMSs also placed I/O, concurrency control, and most database system services on the server. In an attempt to reduce the load on the server process, some RDBMSs placed services that control page contents on the client processes. Despite this change, the majority of system services and all I/O services remained on the server, forcing every single page used by the client to be read through the server process.

The centralized server model used during the mainframe era began to break down in light of these new configurations. For example, consider a network with ten workstations and one server where the ten workstations could each process ten million instructions per second (MIPS) and the server could process 25 MIPS. Using the centralized mainframe model wastes most of the 100 MIPS of compute power of the ten client workstations. Adding more workstations just makes the situation worse, since additional workstations add to the load on the server, without adding usable resources. This server-dominant architecture quickly becomes a performance bottleneck.

Distributed Database Architecture

The distributed database architecture used by Objectivity/DB solves the performance bottleneck problems seen in other DBMSs by permitting distribution of database services among machines, including object caching, updates, traversals, and conversion operations for interoperability. I/O services are moved to separate server processes on the machines where the data resides. Concurrency control is centralized and even that overall task can be subdivided between distributed servers. For a visual representation of distributed database architecture, see Figure 2-2 on page 17.

(40)

Distributed Database Architectures Increased Scalability

Increased Scalability

This balanced database architecture gives Objectivity/DB databases increased scalability. Making good use of the CPU resources that centralized

implementation wastes, most of the computation can be done on the same machine as the application. The result is that Objectivity/DB can handle many more client processes than centralized systems can, and the processing power and performance of the ODBMS increases as each new machine is added to the system.

By using a distributed architecture, Objectivity/DB databases can grow to virtually unlimited size and complexity while maintaining a linear performance profile. As a result, Objectivity/DB databases can support Exabytes of data spread physically across many machines. Applications can access this enterprise-wide data transparently, without knowledge of where the data actually resides.

Petabytes of Data

Objectivity/DB was used in a project which built the world's largest database. The SLAC BaBar project used Objectivity/DB to store the results of their High Energy Physics experiments. Data arrived at a rate of around one Terabyte per day. They used 2400 processors to analyze and work with the data. They eventually stored over one Petabyte of data, compressed down to about 895 Terabytes. This overall system architecture with a bank of machines receiving and storing streams of data, more powerful processors analyzing, correlating and refining the data and a group of specialists using the results (perhaps replicated to multiple sites) is common among Objectivity/DB deployments.

High Ingest Rate

Objectivity/DB's distributed, parallel architecture makes it highly suited to building true or near real-time applications. A very high ingest rate benchmark was run on two SGI Origin 32-processor machines.

One machine was used for ingesting streams of data, correlating objects with other objects and storing both the objects and the discovered relationships. The other was used for supporting a heavy load of mixed queries. Objectivity/DB sustained an ingest rate of over one Terabyte per hour while concurrently supporting the query load. The 100 Terabytes of raw data was stored on 120 Terabytes of disk. The competing relational implementations required 300 Terabytes of disk to store the same raw data. Objectivity/DB associations were used to store the relationships between the incoming objects. This mechanism was not only faster than creating JOIN tables, but it also helped remove the need to index every object, as many of the objects were only used after finding related objects with a query.

(41)

Distributed Database Architectures Service-Oriented Architectures

Service-Oriented Architectures

A Service-Oriented Architecture is a group of communicating services, usually connected via Web services.

Figure 4-2 shows a basic Service-Oriented Architecture. In the figure, a service consumer and a service provider are having a conversation made possible because of the way their connections are defined.

Objectivity/DB has J2EE Connector Architecture (JCA) interfaces that have been tested with application servers such as BEA WebLogic and IBM WebSphere. JCA is a protocol used between the service provider and the service consumer.

service response service request Service Provider Service Consumer

Figure 4-2 Basic Service-Oriented Architecture

High-Performance Page Servers

Objectivity/DB server processes perform page read and write operations, with one or more pages containing a cluster of objects. This approach differs from the approach taken by central server architectures, where rows or objects are the unit of transfer between clients and servers. However, most RDBMSs transfer internal data to and from disk as fixed-size pages.

The Objectivity/DB approach of reading objects as clusters and caching them in the client can greatly improve performance, since it reduces the number of times objects need to be read from disk. In many cases, objects needed by an

application will already reside in its shared library’s cache. For a more detailed quantitative analysis of page server and object database architectures, see Appendix A, “Page Server Performance.”

Parallel I/O and Locking

Objectivity/DB servers execute multiple disk I/O requests in parallel, even if the requested objects reside on the same machine. Because Objectivity/DB uses a separate server to manage lock requests, I/O requests can be processed

(42)

Distributed Database Architectures Support for Dedicated I/O servers

independently of lock requests. Even in single machine environments, where the machine host manages both locking and application I/O requests, the machine can process lock requests concurrently with I/O operations.

Support for Dedicated I/O servers

Many server machines offered today are specialized for I/O operations. They are not designed for CPU-intensive applications, and in fact often do not allow user applications to run on them. Because Objectivity/DB separates I/O services from the CPU-intensive system services, it can take advantage of these servers.

Objectivity/DB application processes can directly access the high-speed I/O servers for their objects. Centralized systems instead have to place their server on a different machine, and their applications are forced to access data indirectly through that third machine, losing much of the advantage of the I/O server.

(43)

43

5

Objectivity/DB

This chapter describes the basic database concepts that are common to all Objectivity/DB database applications.

Safe Object Reference Architecture

Objectivity/DB transparently and safely locates the objects you need in the database. Each language binding employs a different technique:

■ Objectivity/C++ guarantees integrity of objects by using smart-pointers instead of direct pointers to access objects. This important architectural feature follows the ODMG guidelines, and protects Objectivity/DB from serious object corruption that can be caused by an errant application.

■ For Objectivity for Java and Objectivity/Smalltalk applications, you access objects through standard references.

Storage for Exabytes of Interrelated Objects

Any Objectivity/DB transaction can transparently and simultaneously access all data in a database through 64-bit object references. For 64-bit file systems, this allows you to access up to approximately 264 (or 2 x 1019) bytes (10,000,000 Terabytes) of data and up to 258 (or 1017) objects. For 32-bit file systems, due to operating system file size constraints, you can access up to 247 (or 1014) bytes (100 Terabytes) of data and up to 242 (or 1013) objects. Many Objectivity customers have successfully developed and deployed federations with tens of thousands of databases, millions of containers, and Petabytes of storage. For up-to-date information about these customers and their experiences, contact your Objectivity sales representative.

(44)

Objectivity/DB Platform Interoperability

Platform Interoperability

Objectivity/DB provides complete interoperability among different

architectures, which are supported combinations of hardware, operating system, and compiler. Objectivity/DB supports a variety of 32-bit and 64-bit architectures on two main types of platforms (Windows and UNIX). Objectivity/DB

applications, servers, and tools can operate in virtually any combination across these architectures.

Objects can be distributed and freely moved across different database architectures and shared among different kinds of machines. Objectivity/DB automatically and transparently handles inherent differences between these architectures, such as byte order, floating point format, and packing and padding alignment. Objectivity/DB translates on the object level and performs translation only when necessary.

Location Independence of Objects

The physical locations of objects are entirely transparent to Objectivity/DB applications. This allows you to locate and relocate objects on any machine without changing applications that access them. For example, for performance reasons you may want to move certain objects to the machine that accesses them most often. If access patterns to these objects change, you can move the objects again dynamically.

Accessing Objects

64-bit OIDs

At the lowest level, Objectivity/DB accesses persistent objects through 64-bit object identifiers (OIDs). Each object in an Objectivity/DB federated database has a unique OID. OIDs allow Objectivity/DB to locate and manage objects with flexibility and safety. OIDs contain information about the database, container, page, and slot where an object is located.

The OID is split into 4 logical components as follows:

■ First 16 bits—Logical database identifier

■ Second 16 bits—Logical container identifier

■ Third 16 bits—Logical page within container

Objectivity Technical Overview. Release 9