XS8602_ASPNET_SessionStateStore.pptx.ppt Page 1 of 19

Transcription

1 This presentation describes the IBM WebSphere extreme Scale ASP.NET session state store provider, including installation, configuration, operations overview, and troubleshooting. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 1 of 19

2 Some ASP.NET operational concepts are explained briefly. However, to get the most out of this presentation, you should be familiar with the WebSphere extreme Scale product, the.net Framework, C# programming, and ASP.NET web application development. The WebSphere extreme Scale session state store provider uses the WebSphere extreme Scale Client for.net to communicate with the WebSphere extreme Scale servers. Therefore, having some knowledge of this.net client is helpful. Separate.NET client IBM Education Assistant training modules are available on the same website as this module, under WebSphere extreme Scale V8.6. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 2 of 19

3 The WebSphere extreme Scale session state store provider is an implementation of the ASP.NET state store provider specification. It allows ASP.NET web applications to save HTTP session state data in a highly-available external cache that is managed by WebSphere extreme Scale servers. Multiple web applications running across multiple web servers can be configured to share the same external cache. HTTP session state can be preserved across web servers running in a web farm or across ASP.NET worker processes in a web garden. In those cases, session state is saved and retrieved from the WebSphere extreme Scale cache, which is also called a grid. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 3 of 19

4 The system on which the target ASP.NET web application is running, must adhere to these requirements. It must have.net Framework V3.5 or later and Microsoft IIS V6.0 or later. The target web application must be configured with the.net Trust Level set to Full and an associated application pool with an identity that has administrator privileges. Each worker process in the associated application pool requires 185 megabytes. A total of 35 megabytes is required for the initial installation and run. However, you should allow up to 2.5 gigabytes for trace logging. The external grid requires either WebSphere extreme Scale V or later or XC10 V2.5 or later. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 4 of 19

5 The WebSphere extreme Scale session state store provider is contained inside the WebSphere extreme Scale Client for.net V assembly. This means that, when the.net client is installed, the WebSphere extreme Scale session state store provider is automatically installed at the same time. Likewise, when the.net client is uninstalled, the WebSphere extreme Scale session state store provider is also uninstalled. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 5 of 19

6 After installing the WebSphere extreme Scale session state store provider, you will need to configure your target ASP.NET web applications to use this session state store provider. Additionally, the WebSphere extreme Scale servers must be configured to create the grid that is used to store the session state data. This section will cover the required ASP.NET web application configuration changes and the WebSphere extreme Scale or XC10 configuration steps. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 6 of 19

7 To configure the target ASP.NET web application, edit its web.config file. If a <sessionstate> element does not exist, add this element and all sub elements as shown in this example. If the element does exist, add a new entry under the <providers> element. Then, set the sessionstate mode attribute value to Custom and the customprovider attribute value to the name of the WebSphere extreme Scale session state store provider. See the sample text highlighted in blue. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 7 of 19

8 The WebSphere extreme Scale session state store provider has several configuration parameters. The name attribute can be set to any unique label; however, it must match the customprovider value. The type attribute contains the strong assembly name and state store provider entry point. When upgrading to a newer version of WebSphere extreme Scale Client for.net, you might need to update the type Version value. The wxspropertyfile is the fully-qualified path to the.net client configuration file to be used by all instances of this ASP.NET web application. When this value is not specified, it defaults to the Client.Net.properties file that is installed with the.net client. If.NET client configuration changes are necessary, you can make changes directly to that file. The wxshostandport, wxsgridname, and wxsmapname attributes specify the WebSphere extreme Scale server connectivity information, including the catalog server host name, TCP port, WebSphere extreme Scale grid name, and map name. The default wxshostandport value of localhost:2809 is only recommended for development prototype purposes and should be changed when the external WebSphere extreme Scale server is configured and operational. The default wxsgridname value of session is the grid name to use with XC10 servers. When connecting to WebSphere extreme Scale servers, this value must match the WebSphere extreme Scale server configured grid name. ASPNET.SessionState is the default wxsmapname value and is the recommended value when connecting to XC10 servers. Similar to the wxsgridname value, when using WebSphere extreme Scale servers, this value must match the WebSphere extreme Scale server configuration. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 8 of 19

9 You must explicitly define the ASP.NET session state store grid for each WebSphere extreme Scale server. First, edit each WebSphere extreme Scale server s objectgrid.xml configuration file. Add a new objectgrid element whose name attribute value matches the WebSphere extreme Scale session state store provider s wxsgridname value in the web applications web.config file. Inside this element, add a backingmap element whose name attribute value matches the WebSphere extreme Scale session state store provider s wxsmapname value in the web applications web.config file. This backingmap has several other attributes that must also be explicitly set. The copymode must be set to COPY_TO_BYTES, lockstrategy must be set to Pessimistic, and the ttlevictortype should be set to LAST_ACCESS_TIME with a timetolive value of 3600 seconds. This last setting causes session state data in the grid to be automatically deleted from the grid when the session s state data has not been accessed in 10 minutes. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 9 of 19

10 Finally, edit each WebSphere extreme Scale server s deployment.xml file. Add an objectgriddeployment element with an objectgridname value that matches the objectgrid name from the objectgrid.xml file. Inside this element, add a mapset element containing a map element with a ref attribute value that matches the objectgrid s backingmap name from the objectgrid.xml file. This mapset element must also have its placementstrategy value set to FIXED_PARTITIONS, which is the default, and its placementscope value set to either DOMAIN_SCOPE, which is the default, or ZONE_SCOPE. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 10 of 19

11 Configuring XC10 for WebSphere extreme Scale session state store provider support is simple. Log into the XC10 server. From within the user interface, create a session data grid. Specify the grid name -- session is recommended. Remember that this grid name must match the WebSphere extreme Scale session state store provider s wxsgridname value in the web applications web.config file. After completing the remaining wizard steps, the grid is automatically configured with a map template named ASPNET.SessionState.*. This template will match all client requests for maps starting with ASPNET.SessionState, including the recommended map name of ASPNET.SessionState. Be sure that the WebSphere extreme Scale session state store provider s wxsmapname value in the web applications web.config file matches this template pattern. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 11 of 19

12 Once the ASP.NET web application and WebSphere extreme Scale servers have been correctly configured and started, HTTP session state data is automatically persisted inside the WebSphere extreme Scale grid. The next slide provides an overview of how the WebSphere extreme Scale session state store provider fits within the HTTP request processing pipeline. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 12 of 19

13 The WebSphere extreme Scale session state store provider runs in the context of the ASP.NET web applications application domain, which in turn runs within the context of an IIS worker process. When an ASP.NET web application receives its first HTTP request, it is loaded into a worker process application domain. At this time, the web application s state store provider is initialized. When the provider is the WebSphere extreme Scale session state store provider, a connection to the WebSphere extreme Scale grid is made and initialization status is posted to the Windows Application Event Log. After initialization completes, the state store provider is requested to provide the session state data for the HTTP request. If this is the session s very first request, then there is no existing session state data. Control is then passed to the web application, where session state data is updated. After the web application completes its request processing, the session state provider persists the updated session state in the WebSphere extreme Scale grid. Finally, the web application s HTTP response is sent to the HTTP request originator. Subsequent HTTP requests within the same session will not result in the initialization step. When the HTTP session times out due to HTTP inactivity, the session state store provider is notified and the associated session state data is removed from the WebSphere extreme Scale grid. If the web application is restarted or unloaded from the worker process due to inactivity, the session state store provider closes the connection to the WebSphere extreme Scale grid. Note that an IIS server hosting multiple ASP.NET web application instances over multiple worker process application domains will result in multiple connections to the WebSphere extreme Scale grid. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 13 of 19

14 This section covers some troubleshooting tips that will enable you to confirm whether the WebSphere extreme Scale session state store provider is configured and running correctly. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 14 of 19

15 As described in the overview section, the WebSphere extreme Scale session state store provider will write two Windows Application Event Log messages during state store provider initialization. This initialization takes place whenever a web application that is using this state store provider is loaded into an IIS worker process application domain. So, you might see multiple pairs of these messages, if you have multiple web applications running simultaneously on the same IIS server. The first entry indicates that the WebSphere extreme Scale session state store provider initialization has begun. If you see an event log entry similar to the CWOBJ2600I entry shown here, your web application has been correctly configured to use the WebSphere extreme Scale session state store provider. If this log entry does not appear, here are some things to check. Verify that the WebSphere extreme Scale Client for.net has been correctly installed. Verify that your ASP.NET web application has been loaded. For example, point a web browser to your web application. And finally, verify that your web application s web.config file has been correctly configured to use this session state store provider. The second WebSphere extreme Scale session state store provider initialization log entry will indicate the initialization status. When the initialization completes successfully, you will see the CWOBJ2601I message that is shown on this slide. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 15 of 19

16 If WebSphere extreme Scale session state store provider initialization fails, then the second initialization log entry will look like the failure entry shown here. The text will include additional error information that is helpful in determining the root cause of the failure. The most common kinds of failure are due to the inability of the WebSphere extreme Scale session state store provider to connect to the WebSphere extreme Scale grid. In the log entry shown here, the WebSphere extreme Scale grid connection failed due to a non-existent.net client properties file. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 16 of 19

17 In addition to the Windows Application Event Log entries, the WebSphere extreme Scale session state store provider also logs messages in the.net client trace and message log files. These logs are typically located under the <installdir>\logs directory. You can determine the log directory that is being used by the WebSphere extreme Scale session state store provider by looking at the first Application Event Log entry. That entry includes your web application s name and the target log directory. Additional sub-directories are created under this top level log directory with directory names in this format: <process name>_<process id>_<application domain_id>_<website name>. For ASP.NET web applications, the process_name label is the program name of your IIS server s worker process, which is typically w3wp.exe. There are several kinds of log files in this directory. Informational and status messages are located in SystemOut.log and error messages are located in SystemErr.log. In some cases, looking at the system trace log files can also be helpful. These logs contain the informational, warning, and error messages, plus other helpful internal information that might provide additional hints about the root cause of the issue. If you need to contact IBM Support to resolve an issue, all of the files in this directory are likely to be requested. XS8602_ASPNET_SessionStateStore.pptx.ppt Page 17 of 19