Storing Data

There are cases where an object must be stored in a place that can be accessed by different parts of an application. For example, an application may store information about the user that is currently logged in, or a selection that the user has made and that affects different parts of the application. But there are also instances that should be shared between all users, for example actual whether data in a flight control system, or a cache for results of frequent calculations.

When storing those data in RAP, it's important to take into account that the Java VM and the file system are shared by multiple users and perhaps even different RAP applications. Thus, the classical Singleton approach should not be used in RAP. When there are multiple users and applications, data must be stored in a place that is suitable for its scope. RAP provides basic data stores for the different scopes.

Application-wide (shared) data

Especially when an application must handle a lot of parallel user sessions, it's crucial to limit the memory and CPU cycles consumed by a single UI session. Depending on the application, it may be a good idea to share instances of objects that are not user-specific between all users instead of creating an equivalent instance for every single UI session.

An application can store those shared objects as attributes in the ApplicationContext. This makes them accessible for all UI sessions within the application. But in contrast to singletons, the objects won't be available in a different application. When the application is stopped, the application context is cleared and the shared instances can be cleaned up by the garbage collector.

UI-specific data

Some shared information are only valid for the current instance of the entrypoint, i.e. the current UI session. As an example, in a call center application, the customer record that is currently selected is only valid for the current UI session. At the same time, another agent is talking to another customer.

Those objects can be stored as attributes in the UISession. The attributes of a UI session will be cleaned up when the UISession ends.

User-specific data

When a user reloads the page in the browser or switches to another entrypoint, a new UI session is created. All information that was stored in the previous UISession is lost. But it's still the same user. Most applications will remember the user and not ask for a login again.

As usual in web applications, information about the current user should be stored in the HttpSession. RAP applications can access the HttpSession using UISession#getHttpSession().

Persistent User Settings

Some applications allow their users to do certain customizations such as choosing between metric vs. imperial units. Those user settings should be preserved for a longer period of time. RAP provides a simple persistent store for this kind of settings, the SettingStore. The setting store identifies a returning user by means of a cookie. The default implementation stores settings in Java .properties files on disk, but the mechanism also allows for custom implementations:

public class SimpleConfiguration implements ApplicationConfiguration {

  public void configure( Application application ) {
    ...
    application.setSettingStoreFactory( new MyDatabaseSettingStoreFactory() );
    ...
  }

}

An instance can be obtained from RWT.getSettingStore(). In contrast to the other stores, the setting store can only keep strings, not arbitrary objects.

Note that the settings store relies on cookies, which may be deleted or disabled by the user. It is also possible to identify the user by any other means and use the method loadById to initialize the setting store from preserved data.

public class MyDatabaseSettingStoreFactory implements SettingStoreFactory {

  public SettingStore createSettingStore( String storeId ) {
    SettingStore result = new MyDatabaseSettingStore();
    try {
      result.loadById( storeId );
    } catch( Exception exception ) {
      // exception handling
    }
    return result;
  }

}

Overview

All these data stores have at least the three methods setAttribute, getAttribute and removeAttribute.

Please keep in mind that these data stores keep data in memory and are not suited for large or sensitive data structures.

A reference to any of these data stores can only be obtained in the the context of a UISession. That is, they are directly accessible from a UI thread, but background threads need to execute code in the context of a UI session (see Threads in RAP).