Spring Data

An entity is a persistent domain object. Each entity class generally represents a single database table, and an instance of such a class contains the data of a single table row. Each entity instance always has a unique object identifier, which is the same thing to an entity that a primary key is to a database table.

An entity manager factory creates entity manager instances. All entity manager instances created by the same entity manager factory will use the same configuration and database. If you need to access multiple databases, you must configure one entity manager factory per used database. The methods of the entity manager factory are specified by the EntityManagerFactory interface.

The entity manager manages the entities of the application. The entity manager can be used to perform CRUD (Create, Read, Updated, and Delete) operations on entities and run complex queries against a database. The methods of an entity manager are declared by the EntityManager interface.

A persistence unit specifies all entity classes, which are managed by the entity managers of the application. Each persistence unit contains all classes representing the data stored in a single database.

A persistence context contains entity instances. Inside a persistence context, there must be only one entity instance for each object identifier. Each persistence context is associated with a specific entity manager that manages the lifecycle of the entity instances contained by the persistence context.

The Java Persistence API introduced two new methods for creating database queries: Java Persistence Query Language (JPQL) and the Criteria API . The queries written by using these technologies do not deal directly with database tables. Instead, queries are written over the entities of the application and their persistent state. This ensures, in theory, that the created queries are portable and not tied to a specific database schema or database provider.

It is also possible to use SQL queries, but this ties the application to a specific database schema. If database provider specific extensions are used, our application is tied to the database provider as well.

Next we will take a look at how we can use the Java Persistence API to build database queries by using SQL, JPQL, and the Criteria API. Our example query will fetch all contacts whose first name is "John" from the database. This example uses a simple entity class called Contact that represents the data stored in the contacts table. The following table maps the entity's properties to the columns of the database:

//Obtain an instance of the entity manager
EntityManager em = ...

//Build the SQL query string with a query parameter
String getByFirstName="SELECT * FROM contacts c WHERE c.first_name = ?1";

//Create the Query instance
Query query = em.createNativeQuery(getByFirstName, Contact.class);

//Set the value of the query parameter
query.setParameter(1, "John");

//Get the list of results
List contacts = query.getResultList();

//Obtain an instance of the entity manager
EntityManager em = ...

//Build the JPQL query string with named parameter
String getByFirstName="SELECT c FROM Contact c WHERE c.firstName = :firstName";

//Create the Query instance
TypedQuery<Contact> query = em.createQuery(getByFirstName, Contact.class);

//Set the value of the named parameter
query.setParameter("firstName", "John");

//Get the list of results
List<Contact> contacts = query.getResultList();

//Obtain an instance of entity manager
EntityManager em = ...
//Get criteria builder
CriteriaBuilder cb = em.getCriteriaBuilder();

//Create criteria query
CriteriaQuery<Contact> query = cb.greateQuery(Contact.class);

//Create query root
Root<Contact> root = query.from(Contact.class);

//Create condition for the first name by using static meta
//model. You can also use "firstName" here.
Predicate firstNameIs = cb.equal(root.get(Contact_.firstName, "John");

//Specify the where condition of query
query.where(firstNameIs);

//Create typed query and get results
TypedQuery<Contact> q = em.createQuery(query);
List<Contact> contacts = q.getResultList();

Each value stored by Redis has a key. Both keys and values are binary safe, which means that the key or the stored value can be either a string or the content of a binary file. However, Redis is more than just a simple key-value store. It supports multiple binary safe data types, which should be familiar to every programmer. These data types are as follows:

Redis supports two persistence mechanisms that can be used to store the data set on disk. They are as follows:

You can also enable both persistence mechanisms and get the best of both worlds. You can use RDB for creating backups of your data set and still ensure that your data is safe. In this case, Redis will use the AOF log file for building the data set on a server startup because it is most likely that it contains the latest data.

If you are using Redis as a temporary data storage and do not need persistency, you can disable both persistence mechanisms. This means that the data sets will be destroyed when the server is shut down.

Redis supports master-slave replication where a single master can have one or multiple slaves. Each slave is an exact copy of its master, and it can connect to both master and other slaves. In other words, a slave can be a master of other slaves. Since Redis 2.6, each slave is read-only by default, and all write operations to a slave are rejected. If we need to store temporary information to a slave, we have to configure that slave to allow write operations.

Replication is non-blocking on both sides. It will not block the queries made to the master even when a slave or slaves are synchronizing their data for the very first time. Slaves can be configured to serve the old data when they are synchronizing their data with the master. However, incoming connections to a slave will be blocked for a short period of time when the old data is replaced with the new data.

If a slave loses connection to the master, it will either continue serving the old data or return an error to the clients, depending on its configuration. When a connection between master and a slave is lost, the slave will automatically reopen the connection and send a synchronization request to the master.

The publish/subscribe messaging pattern is a messaging pattern where the message sender (publisher) does not send messages directly to the receiver (subscriber). Instead, an additional element called a channel is used to transport messages from the publisher to the subscriber. Publishers can send a message to one or more channels. Subscribers can select the interesting channels and receive messages sent to these channels by subscribing to those channels.

Let's think of a situation where a single publisher is publishing messages to two channels, Channel 1 and Channel 2. Channel 1 has two subscribers: Subscriber 1 and Subscriber 2. Channel 2 also has two subscribers: Subscriber 2 and Subscriber 3. This situation is illustrated in the following figure:

The publish/subscribe pattern ensures that the publishers are not aware of the subscribers and vice versa. This gives us the possibility to divide our application into smaller modules, which have loose coupling between them. This makes the modules easier to maintain and replace if needed.

However, the greatest advantage of the publish/subscribe pattern is also its greatest weakness. Firstly, our application cannot rely on the fact that a specific component has subscribed to a specific channel. Secondly, there is no clean way for us to verify if this is the case. In fact, our application cannot assume that anyone is listening.

Redis offers a solid support for the publish/subscribe pattern. The main features of its publish/subscribe implementation are: