Why Persist Java Web Sessions with In Memory Data Grid?

As you know, Java web applications have the concept of a Session object that allows them to handle multiple user session. This is because HTTP protocol is stateless and Session is used in maintaining user’s state across multiple HTTP requests.

In a single web server configuration, there is no issue persisting Web Sessions but as soon as you have a multi-server load balanced web farm running your Java web application, you immediately run into the issue of where to persist the Web Session. This is because a load balancer ideally likes to route each HTTP request to any web server that is most appropriate at that time based on the load on all web servers. But, if the Session for this user is kept on a specific web server, then you’re forced to use the sticky session feature of the load balancer so it sends the HTTP requests always to that specific web server where the given Web Session was originally created.

Sticky Sessions are Bad

This sticky session behavior means one web server might get overwhelmed with too many HTTP requests because the Web Session for that user resides on that web server even though you have other web servers sitting idle or with much less load. This of course limits scalability because you cannot solve this issue just by adding more web servers. Additionally, keeping the Web Session object only on one web server also means loss of Session data if that web server goes down for any reason. And, losing Web Session means your users are kicked out of your application and have to log in again.

Regular Session Replication is Slow

To avoid this data loss problem, you must have a mechanism where Web Session is replicated to more than one web server. Here, the leading Servlet Engines (Tomcat, WebLogic, WebSphere, and JBoss) all provide some form of Web Session persistence. They even include some form of Web Session replication but all of them have issues. For example, file based and JDBC persistence is very slow and cause performance and scalability issues. Web Session replication is also very weak because it replicates all Web Sessions to all web servers thereby creating unnecessary copies of the Web Session when you have more than two web servers even though fault tolerance can be achieved with only two copies.

Solution: In-Memory Data Grid

In such situations, a Java in-memory data grid like JvCache is your best bet because it resolves these issues seamlessly without any code changes. JvCache ensures that the Web Session persistence across multiple servers in web cluster is done very intelligently and without hampering your scalability.  JvCache has a caching topology called “Partition-Replica” that not only provides you high availability and failover through replication but also provides you large in-memory session storage through data partitioning. Data partitioning enables you to store large amounts of data by breaking up the data grid into partitions and storing each partition on different server in the data grid.

JvCache Partition-Replica topology replicates the session data of each node to only one other node in data grid. This approach eradicates the performance implications of replicating session data on all servers without compromising the reliability.

In addition, session persistence provided by the web servers (Apache, Tomcat, Weblogic and WebSphere) uses the resource and memory of web cluster. This approach hinders your application performance because the web cluster nodes which are responsible to process the client request are also handling the extra work of session replication and its in-memory storage.  Whereas, you can use JvCache to formulate a data grid on separate boxes other than the ones part of your web cluster. This way you can free the web cluster resources and web cluster can use those resources to handle more and more client requests.

JvCache Web Session Persistence Plug-In

For Web Session persistence, JvCache has implemented session module jvc-sessionprovider.jar as Java filter. JvCache Web Session Filter dynamically intercepts requests and responses and handles session persistence behind the scenes. And, you don’t have to change any of your application code.
Following is example of how the deployment descriptor should look like after defining the
JvCache session filter for your web application.

<session-config>
   <session-timeout>30</session-timeout>
</session-config>
<filter>
   <filter-name>jvc-sessionprovider</filter-name>
   <filter-class> com.alachisoft.jvcache.web.sessionstate.JvCacheStoreProvider</filter-class>
   <init-param>
      <description>Name of running cache that will be used to persist sessionstate.</description>
      <param-name>cacheName</param-name>
      <param-value>mycache</param-value>
   </init-param>
   <init-param>
      <description>configPath is used to load the jvc-client.conf </description>
      <param-name>configPath</param-name>
      <param-value>%JVC_HOME%/config/</param-value>
   </init-param>
</filter>
<filter-mapping>
   <filter-name>jvc-sessionprovider</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
<welcome-file-list>
   <welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Hence, JvCache provides you a much better mechanism to achieve session persistence and replication in web cluster along with performance boost and scalability.

You can use JvCache and try it yourself to see how easily JvCache solves your Web Session persistence and replication issues.

Posted in Uncategorized | Leave a comment

How to Synchronize In-Memory Data Grid with Oracle Database?

Java applications are very popular in high traffic environments. Many web applications, web services applications, and other server-side applications are developed in Java. And, these applications typically process a lot of data coming from a relational database.

But databases quickly become a scalability bottleneck as transaction load increases. And, in-memory data grids are becoming increasing popular for caching data in memory and reducing those expensive database trips so as to remove those bottlenecks. These in-memory data grids can easily scale out and do not become scalability bottleneck.

But, using an in-memory data grid means that you are caching data coming from the database and hence there are two copies of this data. This can cause data integrity problem where data in the database is updated but the in-memory data grid still has the older version of the data. To avoid this issue, you have to synchronize your cached data with the database to ensure that it is always correct.

This is an area that is typically neglected by most in-memory data grids. As a result, developers are hesitant to cache a lot of transactional data because they’re afraid it’ll become stale. And, without caching transactional data, your Java application cannot truly take advantage of an in-memory data grid because most of the data in a typical Java application is transactional.

To handle this problem, JvCache provides database synchronization of the in-memory data grid with Oracle databases. This ensures that even if a third party application modifies data in the database, the in-memory data grid is always kept synchronized with the database.

To do this synchronization, JvCache becomes an Oracle database client and uses Oracle notifications to register interest with the database against a given data set. This data set is basically the data that corresponds to the cached item. The database then triggers a notification whenever data in this data set changes. JvCache catches this notification and either invalidates the corresponding cached item or reloads it from the database by calling a Read-through handler.

JvCache encapsulates all that database synchronization capability inside an Oracle Cache Dependency feature. This way, you don’t have to implement anything to achieve this synchronization.

Oracle Cache Dependency is a great feature provided by JvCache to ensure that your in-memory data grid is always kept synchronized with your database. All you need to do is enable change notifications on your database and after that add your data in cache with OracleCacheDependency having information of database connection string and query.

JvCache creates a connection with your database by providing a connection string and registering your query with the Oracle database. So when any change happens to the related data set of the registered query Oracle database triggers change notification to JvCache. Later on JvCache removes the cached item with OracleCacheDependency from cache so that next time that item should be reloaded in cache with updated values.

Here are the simple steps to use OracleCacheDependency in your Java application:

1. Enable database change notifications to your user by executing this query. You just have to execute it once.

[SQL]
"grant change notification to scott" 

2. Import following jars in your application.

import com.alachisoft.jvache.web.caching.*;
import com.alachisoft.jvcache.runtime.dependencies.*;

3. Now initialize your in-memory data grid, create OracleCacheDependency and add it with your item.

 Cache cache = JvCache.initializeCache("oracleDependencyCache");
cache.clear();

String connectionString = "User Id=scott;Password=test;Data Source=oracle";
String query = "SELECT CustomerID FROM Customers WHERE CustomerID = 006";

CacheDependency orclSync = new OracleCacheDependency(connectionString, query);

cache.insert("Customer:006", "myValue" , orclSync, Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration, CacheItemPriority.Normal); 

You can use JvCache and try it yourself to see how easily JvCache solves your database synchronization issues.


Posted in In-Memory Data Grid, Scaling Java Applications | Tagged , , , , | Leave a comment

How to Scale Java Applications with In-Memory Data Grid?

Java is very popular for developing high traffic enterprise level applications. These may be web applications developed in JSP, web services, or other server type applications. A wide range of these applications belong to Online Transaction Processing (OLTP) category involving millions of transactions.

You can handle this high transaction load by adding more web/app servers at the application tier but you cannot do the same at the database tier. The most you can do is buy more expensive hardware for your database server but that only takes you so far. Therefore, database always becomes a bottleneck and slows down your Java applications and may even grind it to halt if too much load is put on it.

Database being the bottleneck for web server farms

Figure 1: Database Scalability Problem in High Traffic Applications

So, what to do about this? Well, in-memory data grid is becoming more popular for handling such situations. It lets you cache application data in memory and reduce those expensive database trips that are overwhelming your database server. And, unlike a database, an in-memory data grid can scale by letting you add more servers at runtime as you increase your transaction load. This ensures that the in-memory data grid never becomes a scalability bottleneck.

An in-memory data grid also lets you persist you JSP Servlet sessions in it. These sessions are then replicated in a multi-server environment so you don’t lose any session data if a server goes down. And, an in-memory data grid is a much faster and more scalable session persistence store than your JSP Servlet container.

JvCache is an in-memory data grid for Java applications. It lets you cache application data and also persist your JSP Servlet sessions in it. JvCache is extremely fast and scalable and provides linear scalability to you. Linear scalability means that as you add more cache servers, your transaction capacity increases in a linear fashion.

Below is an example of using JvCache as an in-memory data grid from Java Application:


import com.alachisoft.jvcache.web.caching.Cache;
import com.alachisoft.jvcache.runtime.*;
...
public class MyCachingSample {
    private String url = "dbc:msql://20.200.20.1:1114/MyDatabase";
    public Employee GetEmployee(String empId) throws Exception
    {
         Employee emp = null;
         try {
              Cache cache = JvCache.initializeCache("MyDistributedCache");
                emp = (Employee) cache.get(empId);
                //If key not found in cache, Load from the database
                if(emp == null)  {
                    ...
                        ResultSet rs = stmt.executeQuery("SELECT * FROM Employee WHERE EmpId ='"+ empId + "'");
                        if (rs.next()) {
                              emp = new Employee();
                              emp.EmpId = rs.getString("EmpId");
                              ...
                              //Cache key for future use
                              cache.insert(empId, emp, null, Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration, CacheItemPriority.Default);
                        }
                }
         }
         catch (Exception exp) {
           throw exp;
         }
         //return the required object
         return emp;
}

JvCache provides a powerful API for the developers to use it as their in-memory data grid and powerful GUI based and command-line administration and monitoring tools for IT folks. This makes JvCache management very simple.
Please download a fully working copy of JvCache Enterprise and try it out for yourself.


Posted in Distributed Cache, In-Memory Data Grid, Scaling Java Applications | Tagged , , , | Leave a comment