CHAPTER 3

image

Bootstrapping Hibernate OGM

Since Hibernate OGM acts as a JPA implementation for NoSQL data stores, it’s obvious we can bootstrap it through JPA. Moreover, it can be bootstrapped through the Hibernate Native APIs as well. No matter which way you choose to bootstrap Hibernate OGM, it’s strongly recommended you use it in a Java Transaction API (JTA) environment, even if you’re not using Java EE.

Before getting into the actual bootstrapping process, let’s take a brief look at these specifications. You’ll want to keep the main features of these technologies in mind over the course of the next sections and chapters. Of course, if you’re already a guru, you can skip ahead.

Brief Overview of JPA

The Java Persistence API aims to provide support for operations that store, update, and map data from relational databases to Java objects and vice versa. You could say that JPA is the perfect tool for developers who have decided to work directly with objects rather than with SQL statements (the ORM paradigm).

image Note   Object-relational mapping is a programming technique that provides a virtual object layer between relational databases and object-oriented programming languages. Programming languages read from and write to relational databases through this layer. Instead of writing SQL statements to interact with your database, you use objects. Moreover, the code is much cleaner and easier to read, since it is not “plumbed” with SQL statements. As this book is written, the JPA specification has several implementations or persistence providers. Some are popular, tested, and stable (EclipseLink, Hibernate and Apache OpenJPA), while others may be less common but have very high benchmark performances (BatooJPA). EclipseLink is the reference implementation of JPA and it works, as every JPA implementation should, in both Java EE environments and standalone Java applications.

JPA is easy to use, thanks to persistence metadata that defines the relationships between Java objects and database tables. You are probably familiar with persistence metadata as JDK 5.0 annotations or XDoclet-style annotations at the language level, which are type safe and checked at compile time.  It could be said that JPA annotations are actually plain JDK 5.0 annotations. Some hide complex tasks. One such annotation is javax.persistence.Entity (@Entity annotation), which is used to mark a POJO Java class that should be persisted in a database—each class annotated with @Entity is stored into a table and each table row is an entity class instance. Entities must define primary keys (a simple or complex primary key, explicitly specified or auto-generated if the @GeneratedValue annotation is present). Entities must not be final and must define a constructor with no arguments. The table name can reflect the class name or it can be explicitly provided through @Table annotation, like @Table(name=" my_table_name ").

An entity class defines a set of fields and each field defaults to a table’s column that has the same name as the field; you can alter this using the  @Column annotation, such as @Column(name=" my_column_name "). JPA can access fields through getter and setter methods. Fields annotated with @Transient won’t be persisted while the other fields are persisted by default.

Entity classes are where you define relationships between and among classes (tables). Classes can have one-to-one (@OneToOne), one-to-many (@OneToMany), many-to-one (@ManyToOne), and many-to-many (@ManyToMany) relationships with other classes. When two classes store references to each other, the relationship is bidirectional and you must specify the owning side of the relationship in the other class with the element mappedBy. When the reference is only from one class to another and not vice versa, the relationship is unidirectional and the mappedBy element isn’t necessary.

Once you have the entities that reflect the database tables, you need an entity manager (an interface between the application and the persistence context, what the Hibernate documentation describes as a “set of entity instances in which for any persistent entity identity there is a unique entity instance,” or, more succinctly, all the entities of one entity manager capable of providing methods for storing, retrieving, merging, and finding objects in the database. In practice, this is the javax.persistence.EntityManager, which is automatically provided in Java EE environments, such GlassFish or JBoss. If you’re in a non-Java EE environment, such as Tomcat or Java SE, you have to manage the EntityManager lifecycle on your own.

The set of entities (usually logically related) that can be managed by a given EntityManager instance is defined as a persistence unit , each of which has a unique name and resides in an XML document named persistence.xml. Persistence.xml is a standard configuration file for JPA. It contains the JPA provider, the JTA or non-JTA data source, the database connection information, such as driver, user, password, DDL generation, and more. (In a Java SE application, this file is usually saved in the source directory in a folder named META-INF, while in a web application it’s typically stored in the /src/conf folder, but, depending on application architecture, it can be located in other places). A persistence.xml file may contain multiple persistence units; based on the one your application uses, the server will know against which database to execute queries. In other words, through a persistence unit the EntityManagerFactory, used by the application to obtain an application-managed entity manager, is configured for a set of entities. You can look at this as a portable way to instantiate an EntityManagerFactory in JPA.

Figure 3-1 shows the relationships among the main components of the JPA architecture.

9781430257943_Fig03-01.jpg

Figure 3-1. Relationships among the main components of the JPA architecture

Well, that was pretty quick. Now let’s take a look at JTA.

Brief Overview of JTA

The Java Transaction API (JTA) enables distributed transactions. Basically, a transaction consists of a set of tasks (for example, SQL statements) that must be processed as an inseparable unit. This is an atomic operation and, in fact, the rule of “one task for all and all tasks for one” is a transaction’s overriding principle. Transactions are characterized by ACID properties, as follows:

  • Atomicity requires that if any of the tasks fail then the transaction fails and it is rolled back. If all tasks are successfully executed, the transaction is committed. In other words, a transaction is an all-or-nothing proposition.
  • Consistency ensures that any committed transaction will leave the database in a valid state (written data must be valid according to all defined rules).
  • Isolation means that your transaction is yours and yours alone; no other transaction can touch it because the database uses a locking mechanism to protect the transaction until it ends, successfully or otherwise. There are four levels of isolation:
  • Read Uncommitted: your transaction can read the uncommitted data of other transactions (never recommended in a multi-threaded environment).
  • Read Committed: your transaction can never read uncommitted data of other transactions.
  • Repeatable: your transaction will get the same data on multiple reads of the same rows until it ends.
  • Serializable: this level of isolation guarantees that everything you touch (all tables) remains unchanged during a transaction. It’s the strictest isolation level and, with the most overhead, it causes the most performance bottlenecks.
  • Durability guarantees that any committed transactions are safe, after system crashes.

These concepts are very important since transactions typically modify shared resources.

Generally, there are two ways of managing transactions:

  • Container Managed Transactions (CMT) use deployment descriptors or annotations (transaction attributes). In this case, the container is responsible for starting, committing, and rolling back a transaction. This is the declarative technique of demarcating transactions. In EJB containers, you can explicitly indicate a container-managed transaction using the annotation @TransactionManagement, like this:

    @TransactionManagement(TransactionManagementType.CONTAINER)

  • Moreover, you can tell the EJB container how to handle the transaction via the @TransactionAttribute annotation, which supports six values: REQUIRED (default), REQUIRES_NEW, SUPPORTS, MANDATORY, NOT_SUPPORTED, NEVER. For example, you can set MANDATORY like this:

    @TransactionAttribute(TransactionAttributeType.MANDATORY)

  • Bean Managed Transactions (BMT) require you to explicitly (programmatically) start, commit, and roll back transactions. This is the programmatic technique of demarcating transactions. In EJB containers, you can explicitly indicate a bean-managed transaction via the annotation @TransactionManagement, like this:

    @TransactionManagement(TransactionManagementType.BEAN)

And there are two types of transactions:

  • local transactions access and update data on a single networked resource (one database).
  • distributed transactions access and update data on two or more networked resources (multiple databases).

Programmatically speaking, JTA is a high-level API for accessing transactions based on three main interfaces:

  • UserTransaction: The javax.transaction.UserTransaction interface allows developers to control transaction boundaries programmatically. To demarcate a JTA transaction, you invoke the begin, commit, and rollback methods of this interface.
  • TransactionManager: The javax.transaction.TransactionManager allows the application server to control transaction boundaries.
  • XAResource: The javax.transaction.xa.XAResource is a Java mapping of the standard XA interface based on the X/Open CAE Specification. You can find more details about XA at www.en.wikipedia.org/wiki/X/Open_XA and about XAResource and at www.docs.oracle.com/javaee/6/api/javax/transaction/xa/XAResource.html.

And that was a quick look at JTA.

MongoDB and Transactions

MongoDB does not support transactions, and this might seem like a limitation that cancels any potential benefit. MongoDB supports atomicity only when the changes affect a single document or multiple subdocuments of a single document. When changes (such as write operations) affect multiple documents, they are not applied atomically, which may lead to inconsistent data, other operations that interleave, and so on. Obviously, since the changes to multiple documents are not atomic, rollback is not applicable.

MongoDB does better with regard to consistency and durability. MongoDB write operations can be made consistent across connections. Moreover, MongoDB supports near-real-time replication, so it’s possible to ensure an operation has been replicated before returning.

Hibernate OGM mitigates MongoDB’s lack of support for transactions by queuing all changes before applying them during flush time. Even though MongoDB doesn’t support transactions, Hibernate OGM recommends using transaction demarcations to trigger the flush operation transparently (on commit). But, as the official documentation indicates, rollback is not an option. Therefore, the applications developed in this book will use JTA, as Hibernate OGM recommends.

image Note   Based on the limitations I’ve noted, it’s easy to conclude that MongoDB can’t meet our application’s needs. But, let’s consider why we might jump to that conclusion. Are we too addicted to complex database schema designs, with many joins and tables that require transactions, and queries that are hard to write and manage? It’s far from my aim to debate such questions here, but maybe you’ll take a little time to think about them and find the correct answers for your applications.

Brief Overview of Hibernate Native API

Applications that use the Hibernate API directly are known as native Hibernate applications. Developing a native Hibernate application consists of a few straightforward steps in which you:

  • define persistence classes
  • specify properties and mapping documents
  • load these into the application’s configuration
  • based on this configuration, create a session factory
  • obtain (open) sessions from the session factory
  • execute queries and transactions

The starting point and core of the Native API is the org.hibernate.cfg.Configuration class, which uses the properties and mapping documents (.properties, .cfg.xml and hbm.xml files) to create org.hibernate.SessionFactory, a thread-safe object that’s instantiated once and provides a factory for obtaining sessions (org.hibernate.Session). Session instances are used to execute transactions (JTA) and/or queries.

Figure 3-2 represents the Hibernate Native API architecture.

9781430257943_Fig03-02.jpg

Figure 3-2. Hibernate Native API architecture

Bootstrapping Hibernate OGM Using JPA

Bootstrapping Hibernate OGM using JPA is the simplest case, since Hibernate OGM acts as a persistence provider. As noted earlier, the persistence provider is specified in the persistence.xml file within a persistence unit. The contents of persistence.xml may differ depending on how certain variables are defined, such as environment (Java EE, Java SE); JTA or non-JTA; database-specific requirements; server configurations; and so on. I tried to write a persistence.xml file for Hibernate OGM that contains the minimum mandatory settings.

  1. The first step is to write a persistence.xml skeleton, which (in a Java SE/EE application) generally looks like this: 
    <?xml version="1.0" encoding="UTF-8"?>
    <persistence version="2.0" xmlns=" http://java.sun.com/xml/ns/persistence "                                              xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
    xsi:schemaLocation=" http://java.sun.com/xml/ns/persistence
    http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd ">
    ...
    </persistence>

    This file is typically saved in the source directory in a folder named META-INF, though in a web application it’s usually saved in the /src/conf folder.

    Next, you add a persistence unit; you can name it whatever you want. JPA implementations can either manage transactions themselves through RESOURCE_LOCAL, or have them managed by the application server’s JTA implementation. You use the transaction-type attribute to specify whether the entity managers provided by the entity manager factory for the persistence unit should be JTA or resource-local. Here I’ll indicate the transaction type as JTA, because we want to use a JTA entity manager. (Whatever the server environment, Hibernate OGM recommends using JTA).

    <persistence-unit name=" {PU_NAME}" transaction-type="JTA">
    </persistence-unit>
    ...

    Remember to not use RESOURCE_LOCAL (a resource-local entity manager) as it uses basic JDBC-level transactions and is more specific to Java SE applications, while JTA is the default in Java EE environments.

  2. Now you need to specify the persistence provider. You’re probably familiar with providers like EclipseLink 2.0 for GlassFish v3, Hibernate 4 for JBoss AS 7, OpenJPA for WebSphere 6 and 7, and OpenJPA/KODO for WebLogic. For Hibernate OGM, the provider is named org.hibernate.ogm.jpa.HibernateOgmPersistence and it can be explicitly added into persistence.xml, like so: 
    ...
    <provider>org.hibernate.ogm.jpa.HibernateOgmPersistence</provider>
    ...
  3. Now we’ve come to the properties section of persistence.xml. The first property to set is the JTA platform using hibernate.transaction.jta.platform. This property can have the following values (these classes belong to Hibernate core; they are the transaction managers as deployed on different application servers):

image Note   Keep in mind that these values were valid when this book was written. They were available in Hibernate 4.1, but it’s quite possible they will change in the future. You can check the list in the Hibernate Developer Guide, at www.docs.jboss.org/hibernate/orm/4.1/devguide/en-US/html_single/.

Here’s an example of setting the JTA platform for Caucho Resin:

...
<property name="hibernate.transaction.jta.platform"
         value="org.hibernate.service.jta.platform.internal.ResinJtaPlatform"/>
...

The next five properties configure which NoSQL data store to use and how to connect to it. For example, you can connect to an out-of-the-box MongoDB distribution by setting the data store provider, grid dialect (optional), database, host and port, like this:

...
<property name="hibernate.ogm.datastore.provider" value="mongodb"/>
<property name="hibernate.ogm.datastore.grid_dialect"
                value="org.hibernate.ogm.dialect.mongodb.MongoDBDialect"/>
<property name="hibernate.ogm.mongodb.database" value="test"/>
<property name="hibernate.ogm.mongodb.host" value="127.0.0.1"/>
<property name="hibernate.ogm.mongodb.port" value="27017"/>
...

That’s it! Now we can glue the pieces together and provide a generic persistence.xml for out-of-the-box MongoDB, as shown in Listing 3-1. In the next chapter we’ll adapt this file to fit into different environments.

Listing 3-1.  A Generic persistence.xml File

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns=" http://java.sun.com/xml/ns/persistence "
                                           xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
xsi:schemaLocation=" http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd ">
  <persistence-unit name=" {PU_NAME}" transaction-type="JTA">
    <provider>org.hibernate.ogm.jpa.HibernateOgmPersistence</provider>
    <properties>
      <property name="hibernate.transaction.jta.platform"
                value=" {JTA_PLATFORM}"/>
      <property name="hibernate.ogm.datastore.provider" value="mongodb"/>
      <property name="hibernate.ogm.datastore.grid_dialect"
                value="org.hibernate.ogm.dialect.mongodb.MongoDBDialect"/>
      <property name="hibernate.ogm.mongodb.database" value="test"/>
      <property name="hibernate.ogm.mongodb.host" value="127.0.0.1"/>
      <property name="hibernate.ogm.mongodb.port" value="27017"/>
    </properties>
  </persistence-unit>
</persistence>

Bootstrap Hibernate OGM Using Hibernate Native API

Earlier, you saw that a native API application can be developed by following a few straightforward steps. Three of these steps—loading properties and mapping files into the application; creating a global thread-safe SessionFactory for the current configuration; and obtaining Sessions (single-threaded units of work)  through SessionFactory—are usually implemented in the well-known HibernateUtil class. (You can write this class, but you also can find it on Internet in different "shapes.") Invariably, in this class, you’ll have some lines of code similar to this (for Hibernate 3):

private static final SessionFactory sessionFactory;
...
sessionFactory = new Configuration().configure().buildSessionFactory();
...

Look at the second line, which builds the SessionFactory through an instance of the org.hibernate.cfg.Configuration class. Actually, this is the entry point to setting Hibernate OGM to work with Native API, because instead of using the org.hibernate.cfg.Configuration class, which is specific to Hibernate ORM, you need to use the org.hibernate.ogm.cfg.OgmConfiguration class. Therefore, that second line will become:

...
sessionFactory = new OgmConfiguration().configure().buildSessionFactory();
...

Starting with Hibernate 4, this code will present a warning about the deprecated method buildSessionFactory(). In this case, the javadoc recommends using the form buildSessionFactory(ServiceRegistry serviceRegistry). So if you are using Hibernate 4 (recommended), replace the previous code with this:

private static final SessionFactory sessionFactory;
private static final ServiceRegistry serviceRegistry;
...
OgmConfiguration cfgogm = new OgmConfiguration();
cfgogm.configure();
serviceRegistry = new ServiceRegistryBuilder().
applySettings(cfgogm.getProperties()).buildServiceRegistry();
sessionFactory = cfgogm.buildSessionFactory(serviceRegistry);
...

This approach (using either Hibernate 3 or 4) requires a hibernate.cfg.xml file that contains specific configurations. For Hibernate OGM, the file needs to contain the correct transaction strategy and the correct transaction manager lookup strategy. You have to specify a factory class for Transaction instances by setting the Hibernate configuration property hibernate.transaction.factory_class. The accepted values are:

  • org.hibernate.transaction.JDBCTransactionFactory—this is the default value and it delegates to database (JDBC) transactions.
  • org.hibernate.transaction.JTATransactionFactory —with this, bean-managed transactions are used, which means you must manually demarcate transaction boundaries.
  • org.hibernate.transaction.CMTTransactionFactory—this value  delegates to container-managed JTA transactions.

Programmatically, you can achieve this setting like this:

...
OgmConfiguration cfgogm = new OgmConfiguration();
...
cfgogm.setProperty(Environment.TRANSACTION_STRATEGY,
" {TRANSACTION_STRATEGY}");
...

Next, you have to specify the JTA platform by setting the property named hibernate.transaction.jta.platform. The value of this property must consist of the fully qualified class name of the lookup implementation. The acceptable values were listed earlier in the "Bootstrap Hibernate OGM Using JPA" section.

Programmatically, you can achieve this setting like this:

...
OgmConfiguration cfgogm = new OgmConfiguration();
...
cfgogm.setProperty(Environment.JTA_PLATFORM," {JTA_PLATFORM}");
...

Finally, you need configure which NoSQL data store you want to use and how to connect to it.

For an out-of-the-box MongoDB distribution, you need to set the data store provider, grid dialect (optional), database, host and port, like this:

...
<property name="hibernate.ogm.datastore.provider">mongodb</property>
<property name="hibernate.ogm.mongodb.database">test</property>
<property name="hibernate.ogm.datastore.grid_dialect">
                org.hibernate.ogm.dialect.mongodb.MongoDBDialect</property>
<property name="hibernate.ogm.mongodb.host">127.0.0.1</property>
<property name="hibernate.ogm.mongodb.port">27017</property>
...

Programmatically, you can achieve these settings with the code in Listing 3-2.

Listing 3-2.  Configuring MongoDB as the Data Store

...
OgmConfiguration cfgogm = new OgmConfiguration();
...
cfgogm.setProperty("hibernate.ogm.datastore.provider","mongodb");
cfgogm.setProperty("hibernate.ogm.mongodb.database","test");
cfgogm.setProperty("hibernate.ogm.datastore.grid_dialect ","
                    org.hibernate.ogm.dialect.mongodb.MongoDBDialect");
cfgogm.setProperty("hibernate.ogm.mongodb.host","127.0.0.1");
cfgogm.setProperty("hibernate.ogm.mongodb.port","27017");
...

Therefore, if you are using non-programmatically settings then the hibernate.cfg.xml may look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" " http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd ">
<hibernate-configuration>
  <session-factory>
    <property name="hibernate.transaction.factory_class">
       { TRANSACTION_STRATEGY }
    </property>
    <property name="hibernate.transaction.jta.platform">
       {JTA_PLATFORM}
    </property>
    <property name="hibernate.ogm.datastore.provider">mongodb</property>
    <property name="hibernate.ogm.mongodb.database">test</property>
    <property name="hibernate.ogm.datastore.grid_dialect">
       org.hibernate.ogm.dialect.mongodb.MongoDBDialect</property>
    <property name="hibernate.ogm.mongodb.host">127.0.0.1</property>
    <property name="hibernate.ogm.mongodb.port">27017</property>
    <mapping resource="..."/>
    ...
  </session-factory>
</hibernate-configuration>

Listing 3-3 shows the HibernateUtil class that uses this configuration file.

Listing 3-3.  ibernateUtil

import java.util.logging.Level;
import java.util.logging.Logger;
import org.hibernate.SessionFactory;
import org.hibernate.ogm.cfg.OgmConfiguration;
import org.hibernate.service.ServiceRegistry;
import org.hibernate.service.ServiceRegistryBuilder;

/**
 * HibernateUtil class (based on hibernate.cfg.xml)
 *
 */
public class HibernateUtil {

    private static final Logger log = Logger.getLogger(HibernateUtil.class.getName());
    private static final SessionFactory sessionFactory;
    private static final ServiceRegistry serviceRegistry;

    static {
        try {
            // create a new instance of OmgConfiguration
            OgmConfiguration cfgogm = new OgmConfiguration();

            //process configuration and mapping files
            cfgogm.configure();
            // create the SessionFactory
            serviceRegistry = new ServiceRegistryBuilder().
                 applySettings(cfgogm.getProperties()).buildServiceRegistry();
            sessionFactory = cfgogm.buildSessionFactory(serviceRegistry);
        } catch (Throwable ex) {
            log.log(Level.SEVERE,
                    "Initial SessionFactory creation failed !", ex);
            throw new ExceptionInInitializerError(ex);
        }
    }

    public static SessionFactory getSessionFactory() {
        return sessionFactory;
    }
}

If you’re using programmatic settings, you don’t need a hibernate.cfg.xml file and your HibernateUtil will look like what’s shown in Listing 3-4.

Listing 3-4.  A HibernateUtil Class That Doesn’t Need Hibernate.cfg.xml

import java.util.logging.Level;
import java.util.logging.Logger;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Environment;
import org.hibernate.ogm.cfg.OgmConfiguration;
import org.hibernate.service.ServiceRegistry;
import org.hibernate.service.ServiceRegistryBuilder;

/**
 * HibernateUtil class (no need of hibernate.cfg.xml)
 *
 */
public class HibernateUtil {

    private static final Logger log = Logger.getLogger(HibernateUtil.class.getName());
    private static final SessionFactory sessionFactory;
    private static final ServiceRegistry serviceRegistry;

    static {
        try {
            // create a new instance of OmgConfiguration
            OgmConfiguration cfgogm = new OgmConfiguration();

            // enable transaction strategy
            cfgogm.setProperty(Environment.TRANSACTION_STRATEGY,
                                                "{ TRANSACTION_STRATEGY}");
            // specify JTA platform
            cfgogm.setProperty(Environment.JTA_PLATFORM, "{ JTA_PLATFORM}");

            //configure MongoDB connection
            cfgogm.setProperty("hibernate.ogm.datastore.provider", "mongodb");
            cfgogm.setProperty("hibernate.ogm.datastore.grid_dialect",
              "org.hibernate.ogm.dialect.mongodb.MongoDBDialect");
            cfgogm.setProperty("hibernate.ogm.mongodb.database", "test");
            cfgogm.setProperty("hibernate.ogm.mongodb.host", "127.0.0.1");
            cfgogm.setProperty("hibernate.ogm.mongodb.port", "27017");

            //add our annotated class
            cfgogm.addAnnotatedClass(*.class);

            // create the SessionFactory
            serviceRegistry = new ServiceRegistryBuilder().
               applySettings(cfgogm.getProperties()).buildServiceRegistry();
            sessionFactory = cfgogm.buildSessionFactory(serviceRegistry);
        } catch (Throwable ex) {
            log.log(Level.SEVERE,
                "Initial SessionFactory creation failed !", ex);
            throw new ExceptionInInitializerError(ex);
        }
    }

    public static SessionFactory getSessionFactory() {
        return sessionFactory;
    }
}

Now, the Hibernate Native API presented in Figure 3-2 can be redrawn as in Figure 3-3.

9781430257943_Fig03-03.jpg

Figure 3-3. Hibernate Native API architecture in Hibernate OGM

image Note   Setting up Infinispan with the default configuration (org/hibernate/ogm/datastore/infinispan/default-config.xml) can be accomplished by specifying the value of the hibernate.ogm.datastore.provider property as infinispan. And you can set up Ehcache with the default configuration (org/hibernate/ogm/datastore/ehcache/default-ehcache.xml) by setting the same property to Ehcache. For these two NoSQL products, Hibernate OGM also supports a specific property for indicating an XML configuration file. For Infinispan, this property is called hibernate.ogm.infinispan.configuration_resourcename and for Ehcache it’s hibernate.ogm.ehcache.configuration_resourcename. For Infinispan and Ehcache, therefore, you don’t need to set dialect, database, port and host.

Hibernate OGM Obsolete Configuration Options

With the advent of Hibernate OGM, a set of options from Hibernate ORM are no longer available. Therefore, in accordance with the Hibernate OGM specification, the following options should not be used in OGM environments:

  • hibernate.dialect
  • hibernate.connection.* and in particular hibernate.connection.provider_class
  • hibernate.show_sql and hibernate.format_sql
  • hibernate.default_schema and hibernate.default_catalog
  • hibernate.use_sql_comments
  • hibernate.jdbc.*
  • hibernate.hbm2ddl.auto and hibernate.hbm2ddl.import_file

Summary

After a brief look at the Java Persistence API (JPA), Java Transaction API (JTA), and Hibernate Native API, you saw how to bootstrap Hibernate OGM using JPA and Hibernate Native API. You learned how to write a generic persistence.xml and how to implement a HibernateUtil class for Hibernate OGM. Finally, you saw the list of Hibernate ORM configuration properties that are no longer available in Hibernate OGM.

1 In April 2013 Red Hat, Inc. announced that the next generation of JBoss Application Server would be known as Wildfly. See http://gb.redhat.com/about/news/press-archive/2013/4/red-hat-reveals-plans-for-its-next-generation-java-application-server-project

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset