3 pagine in totale: <<Indietro 1 2 [3]
PersonalRequest.EndRequest
Riepilogando, all'inizio della pagina viene eseguita la funzione StartRequest che prepara il contenuto del FileSession, letto da una directory predefinita, se presente. Quindi viene elaborata la pagina che, con le funzioni apposite, può modificare il contenuto del FileSession. Infine, viene elaborata questa funzione che verifica innanzitutto che ci siano state modifiche al contenuto del FileSession, e solo in questo caso, viene scritto su disco.
Per eseguire operazioni personalizzate al primo accesso di un utente, è presente l'evento " OnStartFileSession " all'interno della classe PersonalRequest. Per "agganciare" una funzione personalizzata all'inizio di sessione (proprio come fa "Session_OnStart" nel global.asax), nel global.asax, e più precisamente, nell'evento "Application_OnStart", è sufficiente scrivere:
AddHandler PersonalRequest.OnStartFileSession, AddressOf NomeFunzioneNella versione attuale della nostra implementazione non è previsto l'evento per la fine di sessione.
Nell'allegato che si può scaricare alla fine di questo articolo, è presente un esempio con il codice sorgente commentato, per chi abbia voglia di approfondire l'argomento.
Cancellazioni e aggiunta dell'identificatore di sessione ad ogni link
Un paragrafo a parte meritano le due tecniche utilizzate per la cancellazione dei file di sessione dopo il timeout e per l'aggiunta in automatico, a tutti i link, dell'identificatore personalizzato di sessione.
All'avvio dell'applicazione viene creato un oggetto web timer, che richiama ogni x minuti, a seconda del parametro "check_file_time" inserito nel web.config, una funzione che controlla se i file presenti nella directory definita nel parametro "default_directory" non sono stati utilizzati per il numero di minuti configurato in "Timeout". Se risulta più vecchio, il file viene cancellato. Alla fine di questa procedura viene assegnato alla variabile globale "Visitatori" della classe "FS" il numero di file presenti che equivalgono agli utenti ancora "attivi" nella nostra web-application. Nel caso non siano presenti utenti, non viene aggiornato il webtimer:
public static void OnTimerEvent(object source, ElapsedEventArgs e)
{
// Vengono letti tutti i files e verificato che non
// siano più vecchi di "x" minuti (così com'è previsto nel
// web.config). Se lo sono, vengono cancellati.
Debug.WriteLine("Check!");
DateTime dt1 = DateTime.Now;
int ageInMinutes=Settings.Timeout;
DirectoryInfo di=new DirectoryInfo(Settings.DefaultDirectory);
foreach (FileSystemInfo entry in di.GetFileSystemInfos("*.bin"))
{
DateTime dt2 = entry.LastAccessTime;
TimeSpan ts = dt1 - dt2;
if (ts.TotalMinutes> ageInMinutes)
entry.Delete();
}
int quanti=di.GetFiles("*.bin").Length;
if (quanti>0)
{
TimerWeb.Interval=Settings.CheckFiles*60000;
TimerWeb.Start();
}
FS.Visitatori=quanti;
}Per la modifica del codice HTML prodotto dalla pagina ASP.NET, viene impostato un oggetto filtro alla classe HttpResponse , che trovate trattata in maniera dettagliata in questo articolo .
Questo codice si basa essenzialmente sulla ricerca all'interno del codice HTML della sequenza di caratteri ".aspx" (si può ampliare anche per altre estensioni se si utilizzano handler personalizzati come ".ashx") ed aggiunge la stringa con l'identificativo di sessione ?sid=xxxxx . Questa tecnica funziona bene anche con codice Javascript all'interno della pagina, ad esempio per l'apertura di pagine in window separate. Non funziona, ovviamente con codice Javascript caricato da file esterno, a meno che non venga utilizzata l'estensione .aspx (o una delle altre gestite da ASP.NET).
E' possibile disattivare l'inserimento in modo automatico dell'identificatore di sessione, modificando in "false" l'attributo "auto_insert_sid" nel web.config. In tal caso, è possibile aggiungere manualmente il codice di identificazione :
<a href="nuova_pagina.aspx?sid=<%=FS.SessionId %>">altra pagina</a>Ambiti di applicazione
Ma quando può far comodo il modulo appena creato?
Sicuramente quando la nostra web application si basa in maniera pesante sulla memorizzazione delle informazioni di ogni singolo utente, il cui riconoscimento debba avvenire in maniera più precisa possibile e la persistenza dei suoi dati non venga compromessa anche da semplici operazioni di aggiornamento del sito, o da un'utopistica scelta, da parte dell'utente, di disabilitare l'utilizzo dei cookie sul proprio browser.
Un esempio di una web application che rispecchia tutte queste necessità è un sito di e-commerce . Secondo alcune statistiche, circa l'1% degli utenti che navigano in rete lo fa con i cookie disabilitati. Se questa percentuale è accettabile per siti di svago, di vario interesse, per argomenti tecnici, un seppur lieve malfunzionamento in un sito di e-commerce provocherebbe danni ecomici al sito stesso. La perdita dell'1% di probabili acquirenti che vedono l'impossibilità di memorizzazione delle proprie preferenze, significa la perdita di soldi, scopo primario di un qualsiasi sito di commercio.
Conclusioni
Le potenzialità di questo modulo non sono ancora complete. Si potrebbe implementare la memorizzazione su un database Sql Server o altro database di pari potenza per permettere, così come già permette le Session di ASP.NET, di essere condivise tra più server, oppure con la memorizzazione in una cartella condivisa tra più server, si potrebbe rendere possibile la gestione in una web farm composta da più server.
Un altro scenario potrebbe prevedere l'utilizzo solo dal momento in cui sarà veramente necessario la memorizzazione di informazioni dell'utente. Ipotizzando la loro implementazione in un carrello, si potrebbe implementare il loro utilizzo solo dal momento della prima memorizzazione di un prodotto da parte dell'utente.
Rimane, come ultimo argomento, le prestazioni. Dovendo caricare ad ogni richiesta un file, si ha un abbassamento di prestazioni globali dell'applicazioni, ma che, testate su una macchina con P4 a 2,40 GHz ha portato peggioramenti di prestazioni intorno al millesimo di secondo per pagina. Valore più che accettabile quando la sicurezza della sopravvivenza delle informazioni è vitale e soprattutto con le garanzie che questo approccio permette. Sopravvive al riavvio della web application, del server, del riciclo di processo può valere qualche millesimo di secondo in più.
Approfondimenti
- ASP.NET 2.0
- Modificare l'output di ASP.NET utilizzando Response.Filter
- #528 - Visualizzare l'errore esteso di ASP.NET in base all'indirizzo IP di connessione
- #560 - Come disattivare completamente il SessionState
3 pagine in totale: <<Indietro 1 2 [3]
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
- Galleria fotografica dinamica con ASP.NET AJAX
- Usare Search come un servizio nei tuoi siti e nei tuoi client
- Mappe nel tuo sito con Virtual Earth
- Integrare Windows Live ID, Contacts e Presence API nelle tue applicazioni
- Introduzione ai cloud based service con Windows Live Services
- Realizzare un custom extender AJAX con ASP.NET 3.5
- Tracciare le modifiche ai dati e allineare i datawarehouse con il Change Data Capture in SQL Server 2008
- Le nuove caratteristiche di IIS 7.0 per sviluppatori e sistemisti
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!