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.



Switching Databases : ATG


In many database-dependent applications, you may want to make changes in an offline database and then switch over your live application so that the inactive database becomes the live database. ATG’s switching facility is based on a class named atg.service.jdbc.SwitchingDataSource. You can use a SwitchingDataSource in place of a regular data source (such as atg.service.jdbc.MonitoredDataSource)

The SwitchingDataSource can be switched between two or more underlying DataSources. All DataSource method calls are passed through to the DataSource specified by the currentDataSource property of the SwitchingDataSource. Note that each DataSource that the SwitchingDataSource points to must be of class atg.nucleus.JNDIReference, with a JNDIName property that points to an application server data source.


Configuring a SwitchingDataSource


$class=atg.service.jdbc.SwitchingDataSource
#
# A map from data source names to data sources
#
dataSources=\
     DataSourceA=/atg/commerce/jdbc/ProductCatalogDataSourceA,\
     DataSourceB=/atg/commerce/jdbc/ProductCatalogDataSourceB

#
# The name of the data source that should be used on startup
#
initialDataSourceName=DataSourceA

repository=/atg/dynamo/service/jdbc/SDSRepository


initialDataSourceName:


The short name for the DataSource that should be used for the currentDataSource on the very first run. On subsequent runs, the initial currentDataSource is obtained from the state recorded in the SDSRepository.


dataSources:


Set to a ServiceMap of DataSources. This property maps short names of DataSources to their Nucleus component path. The following example shows how you might set the dataSources property:

dataSources=FirstDataSource=\
/atg/dynamo/service/jdbc/FirstDataSource,\
  SecondDataSource=\
/atg/dynamo/service/jdbc/SecondDataSource


repository:


Set with a reference to /atg/dynamo/service/jdbc/SDSRepository


Database Switching and Query Caching


If you are using a GSA repository and set the cacheSwitchLoadQueries property of the GSAItemDescriptor to true, the query cache is loaded for a cache switch. If false, the query cache starts out empty after a cache switch.


Database Switching and Repository Caches


If you set the cacheSwitchHot property of the repository component to true, when the repository receives a SwitchingDataSourceEvent of type PREPARE from the SwitchingDataSource, it prepopulates off-line caches with data from the next DataSource. Then, when the switch occurs and the repository receives a SwitchingDataSourceEvent of type SWITCH from the SwitchingDataSource, the caches are not flushed; instead, the off-line caches go live. This can improve performance during and immediately after a database switchover.


Popular Posts