Monday, December 23, 2013

Session Management in ATG Applications : ATG



Note: This is about session management in ATG applications running on third-party application servers

The J2EE specification defines that each web application has its own session object and any attributes added to the session are only accessible from within that web application. The application server is entirely responsible for managing session life cycles; it generates a unique session ID, creates the session, invalidates it, fails it over, etc. An “ATG session” refers to session-scoped components Also, keep in mind that Nucleus components have a tree structure, and can include multiple scopes, with each scope being rooted at a particular component. The root for session-scoped components is /atg/dynamo/servlet/sessiontracking/GenericSessionManager/sessionid/ where sessionid is generated by the application server.


Sharing Session Information Among ATG Applications


You can run multiple ATG applications in the form of WAR files within a single EAR. In this case, you should share session-scoped Nucleus components so that your application will always have access to the same instance of session scoped components. By default, J2EE servers hand out different session objects in each web application visited, even if all requests came from the same browser. Sharing sessions across ATG applications ensures that you can build a J2EE application consisting of multiple WAR files in a single EAR, and each WAR has access to the same session-scoped components. Note that you should never run more than a single ATG EAR per application server instance.

When multiple web applications exist in the ATG EAR file, one of them must be designated as the parent application. Being the parent means that that application’s session ID is used as the basis for creating the ATG session scope root.

By default, ATG makes the <ATG10.2dir>\DafEar\base\j2ee-components\atg_bootstrap.war file the parent web application. The parent context path is /dyn. No additional configuration is required to use this, but your web applications should define the atg.session.parentContextName and atg.dafear.bootstrapContextName parameters in their web.xml to point to the parent web-application as shown:


<context-param>
   <param-name>atg.session.parentContextName</param-name>
   <param-value>/dyn</param-value>
</context-param>
<context-param>
   <param-name>atg.dafear.bootstrapContextName</param-name>
   <param-value>/dyn</param-value>
   <description>The name of the DAF bootstrap WAR context.</description>
</context-param>

The context path the context-param points to must be for a WAR file with the SessionNameContextServlet defined in its web.xml:

<servlet>
   <servlet-name>SessionNameContextServlet</servlet-name>
   <servlet-class>atg.nucleus.servlet.SessionNameContextServlet
   </servlet-class>
</servlet>

Note that there can be only one parent web application specified per EAR file. Therefore, if you change the parent application, be sure to set the context-param to the same values in all web.xml files within your EAR file:

<context-param>
   <param-name>atg.session.parentContextName</param-name>
   <param-value>/portal</param-value>
</context-param>

Note: This information applies only to session-scoped Nucleus components, and does not affect HTTP sessions obtained using atg.servlet.ServletUtil.getDynamoRequest(request).getSession(), which retain a context particular to the current web application.


Managing User Sessions


You can manage user sessions from the Dynamo Component Browser for debugging or administrative purposes. To access the Session Manager, click through the hierarchy:

/atg/dynamo/servlet/sessiontracking/

Click GenericSessionManager to view sessions. Choose the selection criteria, then click the View button. Click an individual session to see its properties.



No comments:

Popular Posts