Retrieving JNDI Variables Edit the Deployment Plan XML file. For each deployment property you want to

Enhancing Java Portlets 7-31 place simultaneously with a refresh of the page, other portlets that rely on that data value may or may not be refreshed with the latest value. Furthermore, when transactions and rendering are tied together in this way, an action such as the user hitting Back in their browser could cause the transaction to be repeated, perhaps creating a duplicate record. In JPS portlets, this situation is solved using the processAction method, which allows an individual portlet to complete a transaction, such as updating a value, before allowing the page rendering to take place. PDK-Java does not have processAction, but you can achieve the same results by submitting data to your servlet through a different mechanism. If you are using Struts for the page flow and control of a portlet, you could use the form tag and transaction tokens to avoid submitting the same parameter twice. Refer to Section 7.3, Building Struts Portlets with Oracle JDeveloper for more information about Struts portlets. Another possibility is to submit data through Edit mode rather than Shared Screen mode. Requests based on full page Show modes, such as Edit mode, are sent only to the portlet that generated the link. Other portlets on the same portal page never even see a render request. Hence, these full page Show modes provide you with the capability to execute a transaction for a portlet separately from the page and its other portlets. Once you have processed the portlets submission, you redirect from the full page Show mode back to the page using the back URL. This action has two desirable effects, as follows: ■ It returns the user to the page from which they came. ■ It clears all traces of the form submission from the browser. As a result, any refreshing of the page is guaranteed to occur after the processing of the data submission. Because the page refresh comes after the submission you can be sure that all portlets on the page will access the updated data and not cause a duplicate submission. This technique is illustrated by a sample portlet in the PDK called the private event submission portlet. It demonstrates submitting a simple form to the portlet and logging the contents of the form. In the private event submission portlet, we overload Edit mode to handle both the data submission and the portlets rendering for personalizations. Note that any of the other full page Show modes Edit, Help, About, and Edit Defaults would be equally effective for this purpose. Edit mode for this portlet includes additional code that first looks for a specific parameter. If this parameter is present, it means that the request represents a private event. The same mode can handle many different private events by using different values for the distinguishing parameter. If the distinguishing parameter does not exist, then Edit mode falls through to the standard portlet personalization logic. After handling the private event, this mode redirects to the page using exactly the same logic that Edit mode uses when a user clicks OK. Refer to EditServlet.java in the sample files for the complete source code illustrating this technique. 7-32 Oracle Fusion Middleware Developers Guide for Oracle Portal

7.2.6 Accessing Session Information

When a user accesses any portal page, Oracle Portal initiates a public unauthenticated session and maintains a cookie to track information about the session across requests. If the user logs in to Oracle Portal, this session becomes an authenticated session of the logged-in user. This portal session terminates when the any of the following occur: ■ The browser session terminates that is, the user closes all the browser windows. ■ The user explicitly logs out. ■ The session times out because the users idle time exceeds the configured limit. As part of the metadata generation, Oracle Portal contacts all of the providers that contribute portlets to the page, if they specify during registration that they get called for some special processing. This call allows providers to do processing based on the user session, log the user in the providers application if needed, and establish provider sessions in Oracle Portal. For Database providers, this call is referred to as do_login and for Web providers it is initSession. Since most Web-enabled applications track sessions using cookies, this API call allows the provider of the application to return cookies. You can utilize the session store to save and retrieve information that persists during the portal session. This information is only available, and useful, to you during the life of the session. You should store only temporary information in the session store. Application developers may use the session store to save information related to the current user session. Data in the session store can be shared across portlets. If the information you want to store must persist across sessions, you may want to store it in the preference store instead. Some common applications of the session store are as follows: ■ to cache data that is expensive to load or calculate for example, search results. ■ to cache the current state of a portlet for example, the current range, or page, of search results displayed in the portlet, or sequence of events performed by user. Before you implement session storage, you should carefully consider the performance costs. Because portlets and providers are remote, it can be a relatively expensive operation to create and maintain even a small amount of information in the session store. For this reason, you may want to avoid altogether any session storage for public pages that are accessed frequently by many users. If scalability is an important concern for you, a stateful application may cause you problems. Stateful applications can impact the load-balancing and failover mechanism for your Oracle Portal configuration. Even though you may deploy multiple Note: When you use this technique, you must take care that the details of your event are persisted somewhere. Since portlet rendering does not happen in the same request cycle as the event processing, any data from the event required to render the portlet must be available from storage. Otherwise, the portlet or the page may lack the data it requires the next time it is rendered. If you need to persist your data, be sure to store it in a qualified manner by the user and portlet reference. Otherwise, you may accidentally associate an event from one userportlet with the rendering of the same portlet for another user on a different page, or even associate the same usersame portlet with a different portlet reference on the same page.