By replicating schema, data dictionaries, lock servers and (optionally) databases, Objectivity/DB provides fault isolation and improved transaction performance. Using Objectivity/HA administration tools or a C++, Java or command line API, Objectivity/DB databases can be organized into logical, geographic, or functional groups called "partitions" that operate autonomously.

Users within each partition remain insulated from network or system failures in distributed environments that include LANs and WANs; they can continue to access information managed locally despite failures outside the partition. Partitions may be dynamically reconfigured as off-line or on-line to regulate access in real time.

Objectivity/DB High Availability also improves performance. Lock server access is always local so there's no need to traverse the WAN to obtain permission to access objects in the database. Similarly, individual databases may be replicated to multiple partitions to speed up local access.

Application users and developers have transparent access across partitions, since Objectivity/DB High Availability maintains the same single logical view of a distributed database provided by Objectivity/DB. Objectivity/HA is configured at runtime by users and administrators who can set up partitions without making any changes to applications that use the object database.

A "quorum" calculation mechanism allows the application to continue to operate despite the failure of one or more distributed database replicas. It guarantees the integrity of the database despite multiple network or server failures. When a database replica comes back on-line after a server or network failure, it is automatically resynchronized with its quorum partners.

Flexible control over the replication of databases is maintained through both administration tools and C++, Java and command line APIs. Database replication also improves read performance, since replicated databases may be located closer to remote users than a single central database.

A "quorum" calculation mechanism allows the application to continue to operate despite the failure of one or more distributed database replicas. It guarantees the integrity of the database despite multiple network or server failures. When a database replica comes back on-line after a server or network failure, it is automatically resynchronized with its quorum partners.

An administrator can create and delete database replicas, as well as assign the relative importance of those replicas; all without making any changes to the application. In addition, a tie-breaker mechanism allows robust hot-failover configurations. The granularity of the data to be replicated may be selected by the database designer according to the application requirements.

• Fault isolation via autonomous partitions
• Runtime configuration with administration tools and C++, Java and command line APIs
• Support for an unlimited number of users
• Public and private operation of partitions
• Database locks maintained by local lock server
• Synchronous data replication
• Automatic resynchronization of off-line databases
• Dynamic quorum calculation mechanism
• Multiple database images can be stored near remote users
• Variable weighting of database replicas supports both master/slave and peer-to-peer configurations
• Variable granularity of replication
• Tie-breaker mechanism
• Replication configuration transparent to applications

• High Availability of business-critical applications and data
• Tolerance of hardware and network failures
• Ease of Administration
• Scalability
• Flexibility
• Improved Performance
• Data integrity assured
• Availability for both reads and updates, even when some replicas are unavailable
• Improved read performance
• Application requirements determine configuration, not database architecture
• Hot-failover

Learn more about Objectivity/DB customer support - click here.