You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Readme.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,13 +42,13 @@ The specific settings available for the new session state module and providers a
42
42
>
43
43
> The most logical partition field for session state is the session ID. The CosmosDB provider has been updated to alway use `"/id"` as the partition key path with the full session ID as the partition value. Pre-existing containers that use a different partition key path (which is any that opted into using partitions previously) will need to migrate to a container that uses `"/id"` as the partition key path. The data is all still good - although, the old partition key path can be dropped when migrating. There is unfortunately no way to simply update the partition key path on an existing container right now. [This blog post](https://devblogs.microsoft.com/cosmosdb/how-to-change-your-partition-key/) is a guide for migrating to a new container with the correct partition key path.
44
44
*:warning:***Potential Breaking Change*** - Added `managedHandler` precondition to module configuration. The old in-box session module used this and it is a reasonable default for avoiding traffic jams. It can be removed from web.config if session is required for non-managed handlers as well.
45
-
*:warning:***Action Required*** Sql provider `RepositoryType` - This new setting provides a little more flexibility for repository configuration beyond a single boolean for in-memory optimized tables. Possible values are `SqlServer|InMemory|InMemoryDurable|FrameworkCompat`. Read about what each configuration is at our [SqlSessionStateProviderAsync](docs/SqlSessionStateProviderAsync.md) doc page.
45
+
*:warning:***Action Required*** Sql provider `repositoryType` - This new setting provides a little more flexibility for repository configuration beyond a single boolean for in-memory optimized tables. Possible values are `SqlServer|InMemory|InMemoryDurable|FrameworkCompat`. Read about what each configuration is at our [SqlSessionStateProviderAsync](docs/SqlSessionStateProviderAsync.md) doc page.
46
46
47
-
> The mechanics of nuget package upgrade results in removing old elements and re-adding the boiler-plate elements in configuration. To restore In-Memory functionality, set 'RepositoryType' to `InMemory`. To continue using an existing non-memory-optimized table without stored procedures, set 'RespositoryType' to `FrameworkCompat`. The recommendation is to update to the new table schema and use stored procedures with `SqlServer`, but this will ignore existing sessions in previously existing tables.
47
+
> The mechanics of nuget package upgrade results in removing old elements and re-adding the boiler-plate elements in configuration. To restore In-Memory functionality, set 'repositoryType' to `InMemory`. To continue using an existing non-memory-optimized table without stored procedures, set 'RespositoryType' to `FrameworkCompat`. The recommendation is to update to the new table schema and use stored procedures with `SqlServer`, but this will ignore existing sessions in previously existing tables.
48
48
* Moved to use `Microsoft.Data.SqlClient` instead of old `System.Data.SqlClient`. This allows for more modern features such as Token Authorization.
49
49
* Added `skipKeepAliveWhenUnused` to all providers. This setting will skip the call to update expiration time on requests that did not read or write session state. This is setting is used at the module level, and is thus exists on all providers. The default is "false" to maintain compatibility. But certain applications (like MVC) where there can be an abundance of requests processed that never even look at session state could benefit from setting this to "true" to reduce the use of and contention within the session state store. Setting this to "true" does mean that a session needs to be used (not necessarily updated, but at least requested/queried) to stay alive.
50
-
* The Sql provider's `UseInMemoryTable` is deprecated. It will continue to be respected in the absence of `RepositoryType`, but is overridden by that setting if given.
51
-
* Sql provider `SessionTableName` - A new setting that allows users to target a specific table in their database rather than being forced to use the default table names.
50
+
* The Sql provider's `useInMemoryTable` is deprecated. It will continue to be respected in the absence of `repositoryType`, but is overridden by that setting if given.
51
+
* Sql provider `sessionTableName` - A new setting that allows users to target a specific table in their database rather than being forced to use the default table names.
52
52
* CosmosDB `collectionId` is now `containerId` in keeping with the updated terminology from the CosmosDB offering. Please use the updated parameter name when configuring your provider. (The old name will continue to work just the same.)
53
53
* Added CosmosDB `consistencyLevel` to allow using a different [Consistency Level](https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels) with the CosmosClient.
54
54
* CosmosDB `connectionProtocol` is obsolete. It will not cause errors to have it in configuration, but it is ignored. The current [CosmosDB SDK chooses the protocol based on connection mode](https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/sdk-connection-modes).
@@ -21,12 +21,12 @@ The old in-box SQL provider allowed for applications to choose between three dat
21
21
* With the temporary option, session state would be stored in a hard-coded well-known table name in the "tempdb" database on the SQL Server specified in the connection string. The "tempdb" database gets cleared upon SQL server reboot, so the data is not kept. The table schema and stored procedures are also cleared in this scenario, but there is a startup procedure that gets registered to re-create session state tables and stored procedures.
22
22
* With the custom option, session state would be stored in a table name given by the developer/administrator. The stored procedures created in the database work against that custom table name.
23
23
24
-
With this new provider, `aspnet_regsql.exe` is no longer required. (Although, compatibility with stores created by 'aspnet_regsql.exe' can be found when using 'RepositoryType=FrameworkCompat'.) When using a `SqlServer` 'RepositoryType' the provider will automatically create tables and stored procedures if they don't already exist. By default, that table name is "hard-coded and well-known" - though it has changed from previous versions to avoid inadvertent compatibility problems. You can change that table name by using the 'SessionTableName' attribute on the provider. Whether or not data is 'temporary' or 'permanent' in this type of repository depends entirely on the connection string used. If the connection string indicates using "tempdb", then the data will be temporary. If it indicates a non-temporary initial database, then the data will survive SQL reboots.
24
+
With this new provider, `aspnet_regsql.exe` is no longer required. (Although, compatibility with stores created by 'aspnet_regsql.exe' can be found when using 'repositoryType=FrameworkCompat'.) When using a `SqlServer` 'repositoryType' the provider will automatically create tables and stored procedures if they don't already exist. By default, that table name is "hard-coded and well-known" - though it has changed from previous versions to avoid inadvertent compatibility problems. You can change that table name by using the 'sessionTableName' attribute on the provider. Whether or not data is 'temporary' or 'permanent' in this type of repository depends entirely on the connection string used. If the connection string indicates using "tempdb", then the data will be temporary. If it indicates a non-temporary initial database, then the data will survive SQL reboots.
25
25
26
-
When using a Memory-Optimized 'RepositoryType' however, data durability is determined by the optimized table schema. Thus, the provider needs to know what settings to apply to any table it creates. If you want permanent data that survives SQL Server reboots, you must use `InMemoryDurable`.
26
+
When using a Memory-Optimized 'repositoryType' however, data durability is determined by the optimized table schema. Thus, the provider needs to know what settings to apply to any table it creates. If you want permanent data that survives SQL Server reboots, you must use `InMemoryDurable`.
27
27
28
28
## Settings for Microsoft.AspNet.SessionState.SqlSessionStateProviderAsync
29
-
1.*RepositoryType* - One of four values. The default is 'FrameworkCompat' for compatibility reasons - unless the deprecated 'UseInMemoryTable' is also set to true, then the default repository type becomes 'InMemory'.
29
+
1.*repositoryType* - One of four values. The default is 'FrameworkCompat' for compatibility reasons - unless the deprecated 'useInMemoryTable' is also set to true, then the default repository type becomes 'InMemory'.
30
30
*`SqlServer` - Use this option to use a regular SQL server configuration for a fresh deployment. This configuration will create a session table and associated stored procedures if they don't already exist. (*Note* - the session table expected/created in by this repository type uses a different data type for storing state, and is thus incompatible with the 1.1 release of this provider.)
31
31
*`InMemory` - Use this option to leverage "[In-Memory Optimized Tables](https://learn.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/introduction-to-memory-optimized-tables?view=sql-server-ver16)" with "[Natively Compiled Stored Procedures](https://learn.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/a-guide-to-query-processing-for-memory-optimized-tables?view=sql-server-ver16)". New in version 2.0, we create natively compiled stored procedures to go along with the memory-optimized table for an additional performance boost. (V1.1 did not use stored procedures at all.) Tables are durable, but the data is not (`SCHEMA_ONLY`) and will be lost on SQL Server restarts.
32
32
*`InMemoryDurable` - The same as above, except with a `SCHEMA_AND_DATA` durable table so session data survives a SQL Server restart.
@@ -36,12 +36,12 @@ The old in-box SQL provider allowed for applications to choose between three dat
36
36
37
37
The provider automatically decides between Framework and V1.1 compat modes in this configuration.
38
38
39
-
2.*SessionTableName* - The provider now allows the flexibility to use a particular table name for storing session instead of always using the hard-coded default.
39
+
2.*sessionTableName* - The provider now allows the flexibility to use a particular table name for storing session instead of always using the hard-coded default.
40
40
41
-
3.*MaxRetryNumber* - The maximum number of retrying executing sql query to read/write sessionstate data from/to Sql server. The default value is 10.
41
+
3.*maxRetryNumber* - The maximum number of retrying executing sql query to read/write sessionstate data from/to Sql server. The default value is 10.
42
42
43
-
4.*RetryInterval* - The interval between the retry of executing sql query. The default value is 0.001 sec for in-memorytable mode. Otherwise the default value is 1 sec.
43
+
4.*retryInterval* - The interval between the retry of executing sql query. The default value is 0.001 sec for in-memorytable mode. Otherwise the default value is 1 sec.
44
44
45
45
5.*skipKeepAliveWhenUnused* - This setting will skip the call to update expiration time on requests that did not read or write session state. The default is "false" to maintain compatibility with previous behavior. But certain applications (like MVC) where there can be an abundance of requests processed that never even look at session state could benefit from setting this to "true" to reduce the use of and contention within the session state store. Setting this to "true" does mean that a session needs to be used (not necessarily updated, but at least requested/queried) to stay alive.
46
46
47
-
6.**[Deprecated]***UseInMemoryTable* - In the absence of a value for `RepositoryType`, this setting will be used to determine whether to use Sql server 2016 In-Memory OLTP for sessionstate. However, if `RepositoryType` is specified, that setting takes priority. You can find more details about using In-memory table for sessionstate [on this blog](https://blogs.msdn.microsoft.com/sqlcat/2016/10/26/how-bwin-is-using-sql-server-2016-in-memory-oltp-to-achieve-unprecedented-performance-and-scale/).
47
+
6.**[Deprecated]***useInMemoryTable* - In the absence of a value for `repositoryType`, this setting will be used to determine whether to use Sql server 2016 In-Memory OLTP for sessionstate. However, if `repositoryType` is specified, that setting takes priority. You can find more details about using In-memory table for sessionstate [on this blog](https://blogs.msdn.microsoft.com/sqlcat/2016/10/26/how-bwin-is-using-sql-server-2016-in-memory-oltp-to-achieve-unprecedented-performance-and-scale/).
<value>The table '{0}' is compatible with current repositories. Use the '{1}' repositoryType instead with the 'SessionTableName' attribute if applicable.</value>
139
+
<value>The table '{0}' is compatible with current repositories. Use the '{1}' repositoryType instead with the 'sessionTableName' attribute if applicable.</value>
0 commit comments