Impostazione ed utilizzo di variabili di Sessioni su Sql Server

Sql Server 2000 può rendersi utile non solo nel caso in cui è necessario persistere informazioni di applicazioni di tipo business ma, spesso, come vedremo in questo breve articolo, può diventare una risorsa fondamentale per aiutare l’elaborazione delle informazioni applicative di classi .Net per il web. La tecnologia ASP.NET nel framework .Net contiene tutto il plumbing necessario per costruire facilmente applicazioni avanzate e scalabili. L’impostazione necessaria per impostare Sql Server come gestore delle variabili di sessione è una operazione semplicissima. Con la creazione di una applicazione web con Visual Studio.Net viene creato automaticamente il file “web.config”. All’interno di questo file si individui la sezione seguente:

 

<!--  SESSIONSTATE SETTINGS

By default ASP.NET uses cookies to identify which requests belong to a particular session.

If cookies are not available, a session can be tracked by adding a session identifier to the URL.

To disable cookies, set sessionState cookieless="true".

-->

<sessionState

  mode="SQLServer"

  stateConnectionString="tcpip=127.0.0.1:42424"

  sqlConnectionString="data source=127.0.0.1;user id=sa;password="

  cookieless="false"

  timeout="20"

/>

 

Si noti come l’attributo “mode” dell’elemento XML “sessionState” sia impostato a “SQLServer” (la capitalizzazione è importante). Gli altri attributi permettono di meglio specificare la modalità e le maniere per raggiungere il nostro servizio Sql Server. Particolarmente interessante è l’attributo “cookieless” che impostato a “true” permette di mantenere, in assenza di cookie lato client, comunque informazioni di sessione utilizzando codici di sessione aggiunte alla URL.

In pratica, durante una sessione di post-back le variabili di sessione vengono lette o scritte più volte in successione. La prima cosa che potrebbe venire in mente è che ASP.NET del .Net Framework acceda a Sql Server più volte in successione. Ciò non corrisponde assolutamente al vero e sarebbe inoltre poco efficiente. Infatti ASP.NET accede principalmente in soli quattro momenti diversi al database e precisamente:

 

1) creazione di un record contenente lo stream della sessione corrente utilizzando la stored procedure: TempInsertStateItemShort;

2) aggiornamento del record di sessione al termine di una transazione di postback TempUpdateStateItemShort

3) rilascio di un record corrispondente ad una sessione utilizzando la stored procedure: TempReleaseStateItemExclusive

4) allocazione e lettura di un record corrispondente ad una sessione utilizzando la stored procedure: TempGetStateItemExclusive