Accessing Session-Global Data

This section is mostly up-to-date with Vaadin 7, but has some information which still needs to be updated.

Applications typically need to access some objects from practically all user interface code, such as a user object, a business data model, or a database connection. This data is typically initialized and managed in the UI class of the application, or in the session or servlet.

For example, you could hold it in the UI class as follows:

Java

  1. class MyUI extends UI {
  2.     UserData userData;
  4.     public void init() {
  5.         userData = new UserData();
  6.     }
  8.     public UserData getUserData() {
  9.         return userData;
  10.     }
  11. }

Vaadin offers two ways to access the UI object: with getUI() method from any component and the global UI.getCurrent() method.

The getUI() works as follows:

Java

  1. data = ((MyUI)component.getUI()).getUserData();

This does not, however work in many cases, because it requires that the components are attached to the UI. That is not the case most of the time when the UI is still being built, such as in constructors.

Java

  1. class MyComponent extends CustomComponent {
  2.     public MyComponent() {
  3.         // This fails with NullPointerException
  4.         Label label = new Label("Country: " +
  5.             getUI().getLocale().getCountry());
  7.         setCompositionRoot(label);
  8.     }
  9. }

The global access methods for the currently served servlet, session, and UI allow an easy way to access the data:

Java

  1. data = ((MyUI) UI.getCurrent()).getUserData();

The Problem

The basic problem in accessing session-global data is that the getUI() method works only after the component has been attached to the application. Before that, it returns null. This is the case in constructors of components, such as a CustomComponent:

Using a static variable or a singleton implemented with such to give a global access to user session data is not possible, because static variables are global in the entire web application, not just the user session. This can be handy for communicating data between the concurrent sessions, but creates a problem within a session.

The data would be shared by all users and be reinitialized every time a new user opens the application.

Overview of Solutions

To get the application object or any other global data, you have the following solutions:

  • Pass a reference to the global data as a parameter

  • Initialize components in attach() method

  • Initialize components in the enter() method of the navigation view (if using navigation)

  • Store a reference to global data using the ThreadLocal Pattern

Each solution is described in the following sections.

Passing References Around

You can pass references to objects as parameters. This is the normal way in object-oriented programming.

Java

  1. class MyApplication extends Application {
  2.     UserData userData;
  4.     public void init() {
  5.         Window mainWindow = new Window("My Window");
  6.         setMainWindow(mainWindow);
  8.         userData = new UserData();
  10.         mainWindow.addComponent(new MyComponent(this));
  11.     }
  13.     public UserData getUserData() {
  14.         return userData;
  15.     }
  16. }
  18. class MyComponent extends CustomComponent {
  19.     public MyComponent(MyApplication app) {
  20.         Label label = new Label("Name: " +
  21.             app.getUserData().getName());
  23.         setCompositionRoot(label);
  24.     }
  25. }

If you need the reference in other methods, you either have to pass it again as a parameter or store it in a member variable.

The problem with this solution is that practically all constructors in the application need to get a reference to the application object, and passing it further around in the classes is another hard task.

Overriding attach()

The attach() method is called when the component is attached to the UI through containment hierarchy. The getUI() method always works.

Java

  1. class MyComponent extends CustomComponent {
  2.     public MyComponent() {
  3.         // Must set a dummy root in constructor
  4.         setCompositionRoot(new Label(""));
  5.     }
  7.     @Override
  8.     public void attach() {
  9.         Label label = new Label("Name: " +
  10.             ((MyUI)component.getUI())
  11.                 .getUserData().getName());
  13.         setCompositionRoot(label);
  14.     }
  15. }

While this solution works, it is slightly messy. You may need to do some initialization in the constructor, but any construction requiring the global data must be done in the attach() method. Especially, CustomComponent requires that the setCompositionRoot() method is called in the constructor. If you can’t create the actual composition root component in the constructor, you need to use a temporary dummy root, as is done in the example above.

Using getUI() also needs casting if you want to use methods defined in your UI class.

ThreadLocal Pattern

Vaadin uses the ThreadLocal pattern for allowing global access to the UI, and Page objects of the currently processed server request with a static getCurrent() method in all the respective classes. This section explains why the pattern is used in Vaadin and how it works. You may also need to reimplement the pattern for some purpose.

The ThreadLocal pattern gives a solution to the global access problem by solving two sub-problems of static variables.

As the first problem, assume that the servlet container processes requests for many users (sessions) sequentially. If a static variable is set in a request belonging one user, it could be read or re-set by the next incoming request belonging to another user. This can be solved by setting the global reference at the beginning of each HTTP request to point to data of the current user, as illustrated in Figure Switching a static (or ThreadLocal) reference during sequential processing of requests.

threadlocal sequentiality hi

Switching a static (or ThreadLocal) reference during sequential processing of requests

The second problem is that servlet containers typically do thread pooling with multiple worker threads that process requests. Therefore, setting a static reference would change it in all threads running concurrently, possibly just when another thread is processing a request for another user. The solution is to store the reference in a thread-local variable instead of a static. You can do so by using the ThreadLocal class in Java for the switch reference.

threadlocal concurrency hi

Switching ThreadLocal references during concurrent processing of requests