# Oracle9iAS Portal Developer Services
Overview of Information Storage

Creation Date: | July 12, 2002
Status: | Draft (1.0)
Version: | PDK Release 2 (9.0.2 and later)

## Introduction

If you have a favorite news channel on TV, you may have also wondered if your television could track your preferences and switch to the right news channel based on who's watching it. Well, if not the television, Oracle9iAS Portal has different ways to store your preferences and other information and show you exactly what you want to see.

While building interactive portal solutions, you often need to store and retrieve different pieces of information. These may be for various purposes, for example:

- allowing the end-users to personalize their portlet with their own unique preferences,
- saving some information specific to the current session,
- storing information in the database for availability to other applications,
- passing on information between multiple screens of the same portlet,
- sharing common data across multiple portlets, and so on.

Oracle9iAS Portal provides an open framework that supports different types of storage mechanisms for these needs to store information and you need to make an informed decision for choosing the optimum design for your information storage requirements. These storage mechanisms include the preference store, the session store and other application data stores.

This document will cover a design level overview about the different alternatives you have to store information using Oracle9iAS Portal:

- Preference Store - Mainly for persisting user preferences as well as other information
- Session Store - Primarily for session related data or caching temporary information
- Application Data Stores - Include Database-backed or File-based stores or any other application specific store

We will also discuss some sample applications, and what kind of solution works best under each scenario.

## Preference Store

A preference store is a mechanism for storing information like user preference data, portlet/provider settings or even portlet data, while using Oracle9iAS Portal. The information stored in the preference store is persistent in the sense that even if you logout and log back in later, you could still access previously saved preferences. The preference store maintains the user preference information and invokes the user preferences whenever the user logs in again. Apart from preferences, the preference store can be used to save other information too.

The Oracle9iAS Portal Developer Kit (PDK) provides two implementations for the preference store - one for web providers through PDK-Java, and the other for database providers through PDK-PL/SQL. The preference store implementations included with the PDK-Java allow you to save your preference data to either a file system or a database, while the PDK-PL/SQL allows you to save preferences to the database alone. Irrespective of the underlying storage mechanism, the API you use to access the preference store is similar.

The preferences stored in the Portal can be scoped at different levels. For example, the developer has an option to scope preferences at the user level (applicable to the specified user only), at the portlet level (applicable to all users of the portlet), at the provider level (applicable across the portlets of the provider) using PDK-Java. You can also choose to implement your preferences such that they are retrieved through a hierarchy of preference-scoping levels. For example consider a scenario where the user has defined a preference called 'Default Number of Records in the portlet' for an Email portlet using PDK-PL/SQL, and it is set with default values at the system and group levels. If a particular user has not defined this preference value at the user level, then the group level preference value would be used. If the group level value was also not defined, then it would default to the value from the system level preferences.

### Personalization Framework

The PDK also provides a personalization framework that utilizes the functionality of a preference store to persist the data associated with the personalization functions of your portlets. Personalization is a feature of portlets that allows page designers or end users to "personalize" the information displayed in portlets. At its simplest level, personalization might let you change the title of a portlet. More complex portlets might use personalization to control how information is displayed or even what information is displayed. You can configure or personalize portlets at two levels:

- page level
- user level

Page level personalizations are established by the page designer by clicking on the Edit Defaults that is displayed next to a portlet when editing a portal page. This is commonly referred to as "Edit Defaults" because the configuration that is established is the default view of the portlet that will be seen by all users that have not established their own user level personalization for the portlet. You can prevent end user customization of the default settings by turning off end user personalization at the page region level.

User level personalizations are established by end users of the portal. Each user can click on the "Customize" link of a portlet and override the default settings with their own.

For more information on personalization, read:

- Understanding the Provider Framework
- Adding Customization to Java Portlets
- A Primer on End-User Personalization for PL/SQL portlets
- Implementing End-User Personalization (PL/SQL)

## Session Store

To utilize the session store, you need to understand what a portal session is. When a user accesses any portal page, Oracle9iAS Portal maintains a cookie to track information about the session, across requests to the portal. A public unauthenticated session is initially created, when the user first accesses the portal. When the user logs in, this session becomes an authenticated session of the logged in user. This portal session terminates when the browser session terminates (i.e. the user closes all the browser windows), specifically logs out or or does not access the portal for a specific period of time. The timeout period is configurable. A portal session exists between the time you first accessed the portal to the time your session ends, based on any of the three possibilities mentioned above.

The session store is a mechanism that the providers can utilize to store and retrieve information that is as persistent as the portal session. This information is only available, and useful, to you during the lifetime of that session. In a similar manner, application developers may use the session store to save their own information related to the current user session. Only temporary information should be stored by application developers in the session store. Also, data in the session store can be shared across portlets.

The information stored in the session store is as persistent as the Oracle9iAS Portal session is, which is mostly the period between the login and logout by the user. If there is a need to store persistent information it should not be done in the session store; the preference store may be a better solution.

The session storage is intended for storing temporary information that is useful to the current session. For example, some common applications that you may use the session store for, are:

- when caching data that is expensive to load or calculate (e.g. search results)
- when caching the current state of a portlet (e.g. current range (or "page") of search results being displayed in portlet, or sequence of events performed by user)

One thing to remember while using the session store with Web Providers is that by doing so, one creates a stateful application that needs to track state information in memory. Similarly one creates a stateful application, if one uses the file-system implementation of preference store.

If scalability is an important concern, stateful applications may have an impact on the load-balancing and fail-over mechanism for the portal configuration. This is because, even though you may deploy multiple middle-tiers accessing the same Portal instance, you would have to implement sticky routing ( where the same node is used for subsequent requests in the same session) to be able to track state. This sticky routing may result in lopsided load-balancing or loss of session data in case a node crashes, impacting fail-over. This is one reason why many developers prefer to build stateless applications. However if scalability is not a concern, then this is not an issue for you.

For more information on Session Store, read:

- Adding Session Storage to Java Portlets
- A Primer on Session Context for PL/SQL portlet
- A Primer on Session Storage for PL/SQL portlets
- Implementing Session Storage with PL/SQL portlets

## Application Data Stores

When you need to store information for the long term, that may also be accessed, analyzed or re-purposed by other applications, you may also choose to save such application data to your own store, possibly a database store, file system store or even an LDAP store. Alternatively, you may need to find ways of handling transient data through application-specific parameter passing.

### Permanent Data

Database Storage is flexible, since you can design your schema to make data accessible in many different ways depending on the application requirements. A single source of data can be shared by applications running on different machines, which makes it easier to load-balance. It also scales better than file system storage, but requires database access as a pre-requisite. Some issues that you need to play close attention to while designing your system include connection pooling, commits and rollbacks, avoiding hard-coded connection strings and so on.

File System Storage does not require a database. It requires a shared file system, however these generally do not scale well for large data sets. Also the data structure and data access path are fixed and inflexible. In this case file and directory privileges, flushing the buffer, overwrites etc. are issues you need to carefully consider.

LDAP Storage is not really suitable for application data. Some level of structuring is available, but is limited to hierarchical structures. It is better suited to store preferences, if the volume of data is small.

### Temporary Data

When you need to just use information that is transient, the purpose of which is solely to pass on some information to another entity, you need to consider application-specific implementations using parameters that can be passed between portlets, or within a portlet itself. Sometimes you may find yourself wondering whether you need to publish a parameter (say, by adding a name-value pair to the URL) or use a session store value to communicate transient information.

Guidelines for Parameter Passing in portlets

You may also find yourself wondering when to use the preference store, the session store or other application data stores. The following sample applications walk you through some scenarios and provide some guidelines for such decisions.

## Sample Applications

In this section we discuss some application scenarios and provide guidelines for choosing the most suitable type of information storage mechanism for that purpose.

### Personalization

Take the case of a News portlet that provides content from some specific URL. There are two News portlets, which are packaged as part of Oracle9iAS Portal, one that delivers product news to the Welcome page, and the other that delivers developer news to the Builder page. Similarly, If you want to build a URL portlet that can be customized by end-users to point to any URL to deliver its content, you could implement end-user personalization by using the preference store. The users' favorite news URL will be saved to the preference store, and they will view their favorite news every time they log in. If their preference changes to another news site, they can just customize their portlet accordingly.

You will observe that the same News portlet is capable of displaying different types of news. This portlet can be personalized both at the page level and the end user level. For example, this portlet could be placed on three different pages:

- your Welcome page where the page designer configures it to display product information news (and turns off user level personalization)
- the Builder page where the page designer configures it to display development news (but allows the portlet to be personalized by each user)
- an end-user might choose to customize the News portlet shown on a different personal Home page so it displays financial news (because that user follows the financial markets closely)

Oracle9iAS Portal provides two special show modes to deal with portlet personalization - the Edit mode, and the Edit Defaults mode.

#### Edit Defaults Mode

A portlet uses edit defaults mode to allow administrators to customize the default behavior of a particular portlet instance. Edit defaults mode provides a list of default customization settings that can be modified to change the appearance and content of that individual portlet for all users.

Page administrators access Edit Defaults from the Edit Page screen. The link is labeled "Edit Defaults" on the banner of the wire frame diagram of that portlet. If you are end-user and you have customize page privileges, then you can add new portlets to the page and access Edit Defaults for the portlets you add. You cannot access Edit Defaults for portlets that were already part of the page. The users are taken to a new page in the same browser window when they click on this link. The portlet typically creates a page representing a dialog box where you specify the default settings for the portlet instance. Once the settings are applied, the users are then automatically returned to the page from which they came.

The configuration that is established is the default view of the portlet that will be seen by all users that have not established their own user level personalization for the portlet. You can also prevent end user customization of the default settings by turning off end user personalization at the page region level.

Guidelines for Portlets in Edit Defaults Mode

#### Edit Mode

Portal users typically access a portlet's edit mode by clicking the Customize link on the portlet banner. The users are taken to a new page in the same browser window when they click on this link. The portlet typically creates a web page representing a dialog box where the portlet settings can be customized. Once the settings are applied, the users are then automatically returned to the page from which they came. Should the portlet banners be turned off, you can also access edit mode from the Customize Page screen when you click the Customize link. The link is labeled "Customize" on the banner of the wire frame diagram of that portlet.

User level personalizations are established by end users of the portal. Each user can override the default settings with their own.

With both the Edit and the Edit Defaults mode, it is preferable that you use the preference store to save user preferences in the portal repository, since the preference store is tightly linked with the provider infrastructure. However you may also choose to implement your own version of the preference store, by using other types of application data stores for saving user preferences. Issues that you would need to consider include preference scoping at different levels, duplicating preference data, when users try to copy the portlet ( say by copying the page through the Portal wizards), or packaging such data so that they can be easily exported/imported along with portlets they are associated with.

Guidelines for Portlets in Edit Mode

### Session-based Application

Take the case of any application that lets users configure some setting for the current session. For example, if you were building a shopping cart portlet that allows a user to buy some items and put them on the shopping cart, you may want to use the session store to keep track of all the current items on the cart.

You need to understand the requirements in detail to decide whether to use session or preference store. In the above stated example, if you think that the users may need the flexibility to put items on their shopping cart across multiple sessions, and finally check out their purchases, you may choose to use the preference store for tracking the items on the cart. You may also decide that your shopping cart is a complex data structure that needs a more specific application data store, instead of using the preference store's set of name-value pairs.

### Database Application

Suppose you need to collect feedback from your users and analyze that feedback, you may consider storing that information to your own database tables. If you're building a Java or JSP portlet, you can make JDBC calls to access your database and save/retrieve information. Once the information is in your own tables, you have permanent access to all the information on which you can run reports, and even use Oracle9iAS Portal's reporting capabilities to analyze that information.

The PDK provides a feedback sample that makes use of JDBC calls to save information to the database.

In this type of scenario, using the preference store or the session store, may not be appropriate.

### Multi-screen Portlet Application

You may need to develop a portlet that takes the user through multiple paths depending on their inputs. Suppose you're building an application for selling apparel online, your portlet may need to take inputs for the user's name, age, sex, and waist size, and accordingly render items from different categories (men's, women's, kids', plus size etc.). In this case, you may choose to implement this as a multi-screen JSP portlet, with a Next button on each JSP that links to the next JSP based on the user's inputs. In such a case, your user's inputs may be saved to the preference store or session store (based on your requirements), and the next JSP would render content based on the saved information.

Another way to go about this is to pass the user's inputs as parameters to the next screen. Using parameters is preferable in the case you do not need to keep the users input for any future use, and if it is solely for communicating transient information. For example in this shopping cart sample, parameters are used to pass on information from the check out screen to the shipment confirmation screen.

### Multi-portlet Application

Another type of application may require one master portlet to drive other portlets that render details for the master key. In such a case, you would just use parameter passing between the portlets and not bother about saving that information to the preference or session store at all.

One thing to remember is that while using parameters, since the caching key includes the URL (which in turn includes the parameter), a new cache key is created for every new parameter value. This causes more cache versions than necessary. Another aspect is that you need to watch out for parameters that may continue to stick (the name-value pair appears on the URL, even after it has been processed), sometimes due to incorrect resetting of the parameter values. For example, while using parameters to choose tabs on a page, which are also interlinked in other ways, the values may not get properly reset based on user's actions. This might happen when you navigate between the tabs using the links, instead of by clicking on the tabs themselves. Your application must take these possibilities into account while considering the most suitable form of information storage. Sometimes, you may also decide to use the session store instead of using parameter passing to bypass such complications.

## Summary

Ultimately, your choice of the type of information storage depends on the nuances of your specific application. Oracle9iAS Portal provides support for all these different types of storages so you can build an optimum solution.

Revision History: |
Revision No | Last Update
1.0 | July 12, 2002

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com/ | Worldwide Inquiries: 1-800-ORACLE1 Fax 650.506.7200 | Copyright and Corporate Info