none
Que relación tienen las variables de Session con las cookies RRS feed

  • Pregunta

  • Hola y saludos a todos

    Hasta donde tenia entendido las variables de Session dependen de las cookies, tenia entendido "aunque al parecer estaba equivado" que al momento de crear una variable de session "Session[""] = <value>" su valor era guardado en el servidor pero que en las cookies se guaradaba algun Id el cual usaba ASP.net para asociarle al navegador el valor de la session y asi reconocerlo...

    Haciendo la siguiente prueba "disculpen por el VB.net para aquellos que no les gusta pero inconcientemente la hice alli en lugar de c#"

    Private Function ActivarSolicitudServiciosAsync(ByVal value As Integer) As IAsyncResult
                Dim del As ActivarSolicitudServiciosDelegate = New ActivarSolicitudServiciosDelegate(AddressOf MyCallback)
                Dim ar As IAsyncResult = del.BeginInvoke(value, Nothing, Nothing)
                Return ar
            End Function
            Private Delegate Sub ActivarSolicitudServiciosDelegate(ByVal value As Integer)
            Private Sub MyCallback(ByVal value As Integer)
                System.Threading.Thread.Sleep(10000)
                Session("abc") = DateTime.Now.Minute
            End Sub
            Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Load
                Dim abc As String = Session("abc")
                Dim ar As IAsyncResult = ActivarSolicitudServiciosAsync(1)
            End

    El código mostrado simplemente crea un delegado el cual se invoca desde el load de la pagina, el delegado tiene un Thread.Sleep(10000). Cuando la pagina ejecuta ActivarSolicitudServiciosAsync debido al proceso asincrono logra cargar la pagina sin problemas y sin haber terminado el sleep y por lo tanto sin haber asignado valor a la variable de Session("abc")

    Lo que me intriga es que al realizar un postback la variable Session("abc") tiene asignado el valor correspondiente que fue asignado con el delegado.

    ¿Por que pasa esto?

    ¿Las cookies no tienen nada que ver?

    Entiendo que en msdn y muchas otras paginas hablan de este tema la cual ya he leido pero me gustaria saber exactamente en concreto ese punto que les pregunto...

    Saludos y gracias

    martes, 13 de mayo de 2014 16:06

Respuestas

  • Cuando desde una página guardas algo en el Session y desde otra página lo recuperas, se usa el ID de sesión (que por defecto se transmite dentro de una cookie) para reconocer cuál es la sesión cuyos datos se recuperan. En ese sentido el Session depende de las cookies.

    Pero mientras estás dentro de una página, el Session es una instancia de la clase HttpSessionState instanciada expresamente para esa página, por lo tanto no depende de las cookies el poder meter algo en el Session y luego recuperarlo más adelante en la misma página.

    El delegado y los métodos asíncronos no tienen nada que ver. Los métodos asíncronos lo que hacen es liberar el hilo de ejecución que estaba procesando esa página. Pero la clase que se había instanciado para procesar esa página no se destruye. Simplemente, a la vuelta del método asíncrono continúa ejecutándose otro hilo distinto sobte la misma instancia de esa clase. Como la referencia del HttpSessionState se guarda en la clase, no se destruye durante el proceso, y los datos del Session permanecen en memoria. Por eso los recuperas más abajo, sin necesidad de que funcionen las cookies.

    Si intentases lo mismo pero salvando los datos en una página y recuperándolos en otra, verías que se pierden si las cookies están deshabilitadas (a no ser que habilites las sesiones sin cookies desde el web.config).

    • Marcado como respuesta AdyIr viernes, 23 de mayo de 2014 1:31
    martes, 13 de mayo de 2014 20:20

Todas las respuestas

  • Cuando desde una página guardas algo en el Session y desde otra página lo recuperas, se usa el ID de sesión (que por defecto se transmite dentro de una cookie) para reconocer cuál es la sesión cuyos datos se recuperan. En ese sentido el Session depende de las cookies.

    Pero mientras estás dentro de una página, el Session es una instancia de la clase HttpSessionState instanciada expresamente para esa página, por lo tanto no depende de las cookies el poder meter algo en el Session y luego recuperarlo más adelante en la misma página.

    El delegado y los métodos asíncronos no tienen nada que ver. Los métodos asíncronos lo que hacen es liberar el hilo de ejecución que estaba procesando esa página. Pero la clase que se había instanciado para procesar esa página no se destruye. Simplemente, a la vuelta del método asíncrono continúa ejecutándose otro hilo distinto sobte la misma instancia de esa clase. Como la referencia del HttpSessionState se guarda en la clase, no se destruye durante el proceso, y los datos del Session permanecen en memoria. Por eso los recuperas más abajo, sin necesidad de que funcionen las cookies.

    Si intentases lo mismo pero salvando los datos en una página y recuperándolos en otra, verías que se pierden si las cookies están deshabilitadas (a no ser que habilites las sesiones sin cookies desde el web.config).

    • Marcado como respuesta AdyIr viernes, 23 de mayo de 2014 1:31
    martes, 13 de mayo de 2014 20:20
  • Cuando desde una página guardas algo en el Session y desde otra página lo recuperas, se usa el ID de sesión (que por defecto se transmite dentro de una cookie) para reconocer cuál es la sesión cuyos datos se recuperan. En ese sentido el Session depende de las cookies.

    Pero mientras estás dentro de una página, el Session es una instancia de la clase HttpSessionState instanciada expresamente para esa página, por lo tanto no depende de las cookies el poder meter algo en el Session y luego recuperarlo más adelante en la misma página.

    El delegado y los métodos asíncronos no tienen nada que ver. Los métodos asíncronos lo que hacen es liberar el hilo de ejecución que estaba procesando esa página. Pero la clase que se había instanciado para procesar esa página no se destruye. Simplemente, a la vuelta del método asíncrono continúa ejecutándose otro hilo distinto sobte la misma instancia de esa clase. Como la referencia del HttpSessionState se guarda en la clase, no se destruye durante el proceso, y los datos del Session permanecen en memoria. Por eso los recuperas más abajo, sin necesidad de que funcionen las cookies.

    Si intentases lo mismo pero salvando los datos en una página y recuperándolos en otra, verías que se pierden si las cookies están deshabilitadas (a no ser que habilites las sesiones sin cookies desde el web.config).


    Muchas gracias por la información Alberto!!!
    viernes, 23 de mayo de 2014 1:31