Session maintenance

[johnbk]

Hi,
I am trying to adopt OraFormFaces and I have a general question about using OraFormsFaces before I dive in , when we embed diffrent forms in different jsf pages..do all these forms share the same session?Or a new session is started for each form embedded? What happens upon event submissions from jsf on the forms..will this also destroy the old session and start a new session? How the global variables are handled?

[wilfred]

I guess your talking about the Oracle Forms session (and its associated database session). With it's default behavior OraFormsFaces will try to start only a single applet instance for the entire web application session. The first page in a session that uses OraFormsFaces will cause the applet to load. When the user navigates away from the page that applet is suspended into the legacy lifecycle cache of the browser. While it is there it keeps running (technically) but it won't be visible in any way. This does mean that things like the periodic heartbeat to the forms server keeps running to keep the session alive.

When the user navigates to a page that uses OraFormsFaces the browser will resume the old applet from the cache. The applet will resume just as it was when it was suspended. Since it is likely the user is now on a different page and wants to see a different form, OraFormsFaces will close all open forms on a resume and start a fresh copy of the form required for the current page.

With this in mind a web browser session should only have a single Forms applet instance and thus a single session at the Forms server with a single session at the database server. Any forms globals or database package variables are part of the session and will survive this suspend/resume cycle.

There's a number of things to keep in mind:

• Mozilla Firefox 3.5 and newer will destroy the page a user is leaving in parallel with creating the page the user is navigating to. This can cause the new page to request an applet before the old page has released/suspended it. If this happens a new applet instance will be created. In the end, this could mean a single web browser session ends up with multiple forms applets of which maximum one is currently showing. There is no way to force which individual applet instance is used on a next page just as there is no way to disable this parallel destroy/create. This means you cannot rely on forms globals, database package variables or other types of state to survive across pages with Firefox.
• With the previous firefox remark in mind, it is always best to not rely on session state at the forms server or database. The session at the JSF application server should be leading as this is the primary session for the user. You could create a session scoped bean to contain session information and pass its values to forms globals with the <off:Formparameter> component. Relying on database package variables as a means of state is getting less reliable in modern applications as well. The JSF web application (as many other web style apps) will use a pool of database sessions where each page request could theoretically be handled by a different database connection. The container will try to give you the same session for each request, but this is not guaranteed. Hence you cannot rely on database session state there either.
• You can alter the default OraFormsFaces behavior if you need to. You can implement a PL/SQL function (shouldFormClose) that decides whether the current form should be closed when the applet resumes on a page. By default this will return true, but you can re-implement it with custom logic. The function gets all attributes of the JSF off:form component and parameters for both the previous and current page. This means you can decide not to close/restart forms unless a different form or different customer was selected (for example)
• Currently there is no easy (documented) way to have different JSPX pages use a different applet instance by definition. This is something that is in the current development version and should be included in version 3.1
• You could opt to set the legacy_lifecycle parameter to false disabling the entire mechanism. That would destroy the applet each time a user navigates away or reloads the page. Each page would start a fresh new applet instance which in most cases significantly impacts performance.

[lesterrebollos]

Hi Wilfred,

Inline with this topic I have seen from you example on 3.0.7 that indeed it's only creating one session when I navigate from one page to another. But I am having issues with our existing forms that was migrated from 6i to 10g. It creates a new session when I navigate from one page to another and back. Right now I don't know if the issue is because it was migrated or what. Here's my scenario:

Test 1:
1. Installed and configured 3.0.7 on jdev 11g and IAS 10.1.2
2. Subclassed,attached and compiled two forms that was migrated from 6i to 10g. (e.g. form1 and form2)
3. Runs a jspx page with tabs , tab1 will load form1 and tab2 will load form2.
4. When I move between these tabs i saw that it creates 2 sessions on the form server.

Test 2:
1. Given the settings above, I created two new forms (e.g. test1 and test2) via forms builder.
2. Subclassed,attached and compiled these two forms
3. Add two more tabs on the jspx page tab3 and tab4, which will load these forms.
4. Found out that these two new forms only creates one session on the forms server.

Do you have any idea what's the issue? Appreciate your response.

[wilfred]

Which browser make, model and version are you using?
If it's Firefox it could create additional sessions since Firefox is using multiple parallel threads to destroy the previous page and construct the new page. This could mean the new page is requesting an applet before the previous page has released it, hence a new instance is being created.