A MySQL Cluster is
defined as one or more MySQL Servers providing access to an
NDBCLUSTER storage engine—that
is, to a set of MySQL Cluster data nodes (ndbd
processes). There are four main access paths from Java to
NDBCLUSTER, listed here:
JDBC and mysqld. JDBC works by sending SQL statements to the MySQL Server and returning result sets. When using JDBC, you must write the SQL, manage the connection, and copy any data from the result set that you want to use in your program as objects. The JDBC implementation most often used with the MySQL Server is MySQL Connector/J.
Java Persistence API (JPA) and JDBC. JPA uses JDBC to connect to the MySQL Server. Unlike JDBC, JPA provides an object view of the data in the database.
a JNI bridge to the NDB API
for direct access to
NDBCLUSTER. It employs a style
of data access that is based on a domain object model,
similar in many ways to that employed by JPA. ClusterJ does
not depend on the MySQL Server for data access.
ClusterJPA. ClusterJPA is an adapter for the OpenJPA implementation. It can use either of two different access paths—JDBC or ClusterJ—to MySQL Cluster data, depending on the type of operation to be performed. This can significantly improve performance for some uses, bypassing SQL, JDBC, and the MySQL Server entirely when it is more efficient to do so.
These paths are shown in the following API stack diagram:
JDBC and mysqld. Connector/J provides standard access through the MySQL JDBC driver. Using Connector/J, JDBC applications can be written to work with a MySQL server acting as a MySQL Cluster SQL node in much the same way that other Connector/J applications work with any other MySQL Server instance.
For more information, see Section 4.2.4, “Using Connector/J with MySQL Cluster”.
ClusterJ is a native Java Connector for
NDB), the storage engine for MySQL
Cluster, in the style of
Like other persistence frameworks, ClusterJ uses the
Mapper pattern, in which data is represented as domain
objects, separate from business logic, mapping Java classes to
database tables stored in the
NDBCLUSTER storage engine.
NDBCLUSTER storage engine is
often referred to (in MySQL documentation and elsewhere) simply
NDB. The terms
synonymous, and you can use either
ENGINE=NDBCLUSTER in a
CREATE TABLE statement to create
a clustered table.
ClusterJ does not need to connect to a mysqld
process, having direct access to
NDBCLUSTER using a JNI bridge that is
included in the dynamic library
However, unlike JDBC, ClusterJ does not support table creation and
other data definition operations; these must be performed by some
other means, such as JDBC or the mysql client.
OpenJPA (ClusterJPA). ClusterJPA is an adapter for OpenJPA that can also bypass JDBC and MySQL Server, using ClusterJ for fast-track access to the cluster. However, for complex queries (not primary key lookups) ClusterJPA uses JDBC.
OpenJPA is an implementation of the JPA (Java Persistence API) specification, which provides an object-relational persistence framework with relationships, inheritance, and persistent classes. See openjpa.apache.org, for more information about OpenJPA.
ClusterJ is independent of ClusterJPA as well as JDBC. However, ClusterJ can be used together with these APIs. Because ClusterJ is limited to queries on single tables, and does not support relations or inheritance, you should use JPA if you need support for these features in your applications.
For more information, see Section 4.2.3, “Using JPA with MySQL Cluster”.
ClusterJPA supports persistent classes, whereas ClusterJ only supports persistent interfaces.
ClusterJPA supports relationships between persistent classes (typically modeled as logical foreign keys), whereas ClusterJ only supports single-valued fields directly mapped to database columns.
ClusterJPA makes it possible for you to formulate queries that contain joins based on relationships in the domain object model, while ClusterJ does not support either relationships or joins.
However, once you retrieve instances using a JPA query, you can update or delete these using the fast path of ClusterJ.
ClusterJPA makes it possible to use the JPA API to declare some fields as lazily loaded, meaning that the data is only brought into memory when your program actually references it. ClusterJ, however, reads all mapped columns from the table whenever you access a row.