Data can be loaded directly from any persistent store into Ignite caches. This example shows you how to load data from a MySQL database into an Ignite distributed cache. Here, I am assuming that you already have Apache Ignite installed on your system. If not, you can go through this tutorial first.


1.  Sample PERSON table

To start with, here is what the PERSON data in my database looks like-

2.  Model 

Here is a sample Person.java class corresponding to the PERSON table in the database.
public class Person {

    private long id;

    private long orgId;

    private String name;

    private int salary;

    // Constructor
    …
    // Getter and Setter methods
    …
}

3. Maven Dependency

I have specified the following dependencies in my project’s pom.xml :
<dependency>
    <groupId>org.apache.ignite</groupId>
    <artifactId>ignite-core</artifactId>
    <version>1.5.0.final</version>
</dependency>

<dependency>
    <groupId>org.apache.ignite</groupId>
    <artifactId>ignite-spring</artifactId>
    <version>1.5.0.final</version>
</dependency>

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.6</version>
</dependency>

4. Configure Read-Through

To load the data from the database, you need to enable the read-through mode and set the cacheStoreFactory property of CacheConfiguration. You can set these values either in your Spring XML configuration file or programmatically.

    
    
    
    



    
        
            
                
                
                
                
                
                
                    
                        
                    
                
                
                    
                        
                            
                            
                            
                                
                                    
                                    
                                    
                                    
                                
                            
                        
                    
                
            
        
    

    

    
    ...

5. Implement CacheStore

Now that we have our model, maven dependencies, and cache configurations in place, it’s time to implement the store. To load the data from the database, loadCache() and load() methods of the CacheStore interface should be implemented.
public class PersonStore implements CacheStore<Long, Person> {

    @SpringResource(resourceName = "dataSource")
    private DataSource dataSource;
    
    // This method is called whenever IgniteCache.loadCache() method is called.
    @Override
    public void loadCache(IgniteBiInClosure<Long, Person> clo, @Nullable Object... objects) throws CacheLoaderException {
        System.out.println(">> Loading cache from store...");

        try (Connection conn = dataSource.getConnection()) {
            try (PreparedStatement st = conn.prepareStatement("select * from PERSON")) {
                try (ResultSet rs = st.executeQuery()) {
                    while (rs.next()) {
                        Person person = new Person(rs.getLong(1), rs.getLong(2), rs.getString(3), rs.getInt(4));

                        clo.apply(person.getId(), person);
                    }
                }
            }
        }
        catch (SQLException e) {
            throw new CacheLoaderException("Failed to load values from cache store.", e);
        }
    }
  
    // This method is called whenever IgniteCache.get() method is called.
    @Override
    public Person load(Long key) throws CacheLoaderException {
        System.out.println(">> Loading person from store...");

        try (Connection conn = dataSource.getConnection()) {
            try (PreparedStatement st = conn.prepareStatement("select * from PERSON where id = ?")) {
                st.setString(1, key.toString());

                ResultSet rs = st.executeQuery();

                return rs.next() ? new Person(rs.getLong(1), rs.getLong(2), rs.getString(3), rs.getInt(4)) : null;
            }
        }
        catch (SQLException e) {
            throw new CacheLoaderException("Failed to load values from cache store.", e);
        }
    }

    // Other CacheStore method implementations.
    …
}

For convenience purposes, Ignite also provides its users with CacheStoreAdapter class that has a default implementation for some of the CacheStore methods - loadAll(), writeAll(), and deleteAll().

6.  Load Cache

Here is a sample PersonStoreExample.java class that makes a call to IgniteCache.loadCache() method which internally delegates the call to CacheStore.loadCache() method (which we implemented in the previous step).
public class PersonStoreExample {
    public static void main(String[] args) throws IgniteException {
        Ignition.setClientMode(true);

        try (Ignite ignite = Ignition.start("config/cluster-config.xml")) {
            try (IgniteCache<Long, Person> cache = ignite.getOrCreateCache("personCache")) {
                // Load cache with data from the database.
                cache.loadCache(null);

                // Execute query on cache.
                QueryCursor<List<?>> cursor = cache.query(new SqlFieldsQuery(
                        "select id, name from Person"));

                System.out.println(cursor.getAll());
            }
        }
    }
}

7. Start Ignite Cluster

From the command shell, lead yourself to the Ignite installation folder and start the server nodes, using the following command -
$ bin/ignite.sh <path-to-Spring-XML-configuration-file>
Make sure that PersonStore.java is in the class path of Ignite. To do so, you can set the USER_LIBS environment variable, or drop the project jar into the libs folder of your Ignite installation.

8. Output

From your IDE, run PersonStoreExample.java.

For more information, documentation, and screencasts, visit the Apache Ignite website.

In a multi-user environment, concurrent transactions on the same set of cache entries can cause deadlocks – an unfavorable situation that adversely affects the performance of any application. Once a system enters a heavy deadlock state, recovery may require a complete cluster re-start. Keeping this in mind, Apache Ignite came up with ACID compliant Deadlock-Free Transactions that can prevent deadlocks and enhance application performance. Before looking into this feature in more detail, let’s briefly go through the basics.

What is a Deadlock?

A deadlock is a situation where a transaction T1 waits indefinitely for a resource R2 that is held by another transaction T2; and T2 waits for a resource R1 that is held by T1.

Data can be loaded directly from any persistent store into Ignite caches. This example shows you how to load data from a MySQL database into an Ignite distributed cache. Here, I am assuming that you already have Apache Ignite installed on your system. If not, you can go through this tutorial first.

1.  Sample PERSON table

To start with, here is what the PERSON data in my database looks like-

2.  Model 

Here is a sample Person.java class corresponding to the PERSON table in the database.

For systems where low latency is critical, there is nothing better than caching the data in memory in a distributed cluster. While storing data in memory provides fast data access, distributing it on a cluster of nodes increases application performance and scalability. And Apache Ignite helps you achieve exactly that.

Ignite data grid is a distributed in-memory key-value store. It can also be viewed as a partitioned hash map that enables caching data in-memory over multiple server nodes.

This tutorial shows you how to create a simple ‘Hello World’ example in Apache Ignite.

The following technologies were used in this example:

Java Development Kit (JDK) 1.8 Apache Ignite 1.5.0-b1 Maven 3.1.1 IntelliJ IDEA 15 CE

Note: JDK 1.7 or above is required.

1.

Businesses are accumulating data at enormous rates requiring huge amounts of storage. Managing large data is hard, but processing it is even more challenging. With terabytes of data to store and process, it is often the case that developers find themselves in a quandary about how to strike the right balance between speed, scalability, and cost. 

Storing data in cache can significantly enhance the speed of your application.

In a distributed environment, deploying a user-defined data structure as cluster wide service can provide access to all its operations, from anywhere in the grid. For example, you can have your own implementation of a distributed SecureMap, which auto-encrypts its values and is deployed as a service on all the cluster nodes.

In GridGain, you can implement your own custom data structures and deploy them as distributed services on the grid.

When storing data in a distributed cache, Map is the most obvious data structure. But, there are times when applications need to process data in the order it is received. GridGain In-Memory Data Fabric, in addition to providing standard key-value map-like storage, has an implementation of fast Distributed Blocking Queue.

As an implementation of java.util.concurrent.BlockingQueue, GridGain Distributed Queue also supports all operations from java.util.Collection interface.

Failing-over web session caching is problematic when you run multiple application servers. It is not uncommon for web applications to run in a cluster to distribute the load of high volume of web requests. But what if one of the application servers crashes? The load balancer will just route the web request to another available application server, but all of user’s session data is lost.
Blog Archive
Loading
Dynamic Views theme. Powered by Blogger.