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.
ClusterJ. ClusterJ uses 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 via 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.
ClusterJ is a native Java Connector for
NDBCLUSTER (or
NDB), the storage engine for MySQL
Cluster, in the style of
Hibernate,
JPA,
and JDO. Like
other persistence frameworks, ClusterJ uses the
Data
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.
Note
The NDBCLUSTER storage engine is
often referred to (in MySQL documentation and elsewhere) simply
as NDB. The terms
NDB and
NDBCLUSTER are synonymous, and you
can use either ENGINE=NDB or
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 libnbdclient.
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”.
Differences Between ClusterJPA and ClusterJ. While ClusterJPA and ClusterJ are similar in many ways, there are importance differences between the two, highlighted in the following list.
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 allows 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 via the fast path of ClusterJ.
ClusterJPA allows you 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.
