aplicación web sin Sesiones (session-less)

Estas en lo correcto.

Pero porque anular las sesiones por completo. El unico motivo valido seria
el no tener la posibilidad de colocar cookies en el cliente, por lo que las
sessions no funcionarian.

En el caso de que elimines las sessions por completo, no podrias mantener
informacion del usuario entre paginas, como podrias identificarlo? Si usas
un cookie para almacenar informacion critica, este puede ser facilmente
modificable, y el usuario podria acceder a datos no permitidos.

Posiblemente si vemos porque quieres no usar sessions, cual es la finalidad
de tu aplicacion web, podriamos encarar mejor el problema.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net - DCE3
"bajopalabra" escribió en el mensaje
news:
Mostrar la cita

además,
me parece que antes de entregar cada página
tendría que consultar si el "id de sesión" de la página
(vía cookie, get o post) coinicide con el guardado
en la tabla de "sesiones"

teniendo que establecer una conexión nueva
creando y liberando objetos ADO ...

pero todo eso también es overhead

por lo tanto me parece más costoso
session-less que utilizar sesiones
ya que con estado de sesion utiliza memoria y algo de cpu

mientras que sin sesión (manteniendo el id con cookie/get/post)
utilizará más cpu por validar sesión en cada página,
más memoria ya que necesita establecer 2 conexiones más
y utilizar objetos ADO con mucha frecuencia
y además operaciones red y de Entrada/Salida contra la base de datos

no te parece ?
estoy errado ?

atte, Hernán

"Matías Iacono" escribió en el mensaje
news:
Mostrar la cita

Si trabajas con ASP 3.0, el manejo de session sin sessions debes hacerlo

por
Mostrar la cita

tu lado.

Podrias tener una base de datos, para almacenar la informacion de cada
usuario. En la misma tabla, un campo de tipo hora para saber cuando fue
la
ultima vez que ese usuario hizo un requerimiento. De esta manera, podrias
saber cuanto tiempo de inactividad ha pasado para ese usuario.

Ademas, claro esta, que deberias tener un cookie o (en el caso de que

esten
Mostrar la cita

desabilitados) mantener el ID en la barra de navegaciones y arrastrarlo
pagina a pagina, algo asi como hace .Net.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net - DCE3
"bajopalabra" escribió en el mensaje
news:
> hola
> si deshabilito las sesiones
> cómo identifico la sesión de un usuario ?
>
> suponiendo, que genero mi propio "id de sesión" para cada login
> (el que arrastro por cada página del sitio para no perderlo)
> cómo puedo, luego, saber que una sesión ha terminado ?
> recuerdo que el evento Session_OnEnd( ) no siempre funciona bien..
>
> atte, Hernán
>
> atte, Hernán
>
>

bien, trabajo con sql server 2000

yo pienso lo mismo, obtener los datos al necesitarlos
el problema es que necesitaría pegarle a la base de datos
cada vez que debo entregar la página y eso sucede
con mucha frecuencia

estoy de acuerdo en lo de ocultar opciones de menú
es así como funciona actualmente

pero el cambio que debo introducir
requiere variables con más de un valor : arrays

el stored proc para armar los menúes
hace 7 consultas ( una por cada perfil )
tiene un tiempo de acceso de 90 ms = 0.09 segundos
sin contar el tiempo de instanciar ADO,
de conexión, red, y liberar recursos...
supongamos a grosso modo 200 ms en obtener un menú
y eso puede suceder por ej. cada 10 segundos
ya que cada click del usuario vuelve a pedir el menú ...

ahora te comprendo lo de los frames
nunca los utilicé porque entendía que estaban
dejando de utilizarse... es así ?

con todo, de no poder utilizar frames
te parece mejor consultar la BD cada vez
que debo entregar una página ?
o guardarlo en sesiones ?

gracias nuevamente por tu interés y dedicación

atte, Hernán

"Matías Iacono" escribió en el mensaje
news:
Mostrar la cita

Pues te haz tomado el trabajo!! :D

Con que base de datos trabajas?

Te pregunto esto, debido a que, personalmente, conseguiria mayor desempeño
sacando los datos en el momento de necesitarlos. Si tu aplicacion lo
permite, podrias tener un frame para este menu, para que solo sea cargado
una vez, y recargas la DB solo esa vez.

Otra alternativa seria tener las variables session normales, pero si el

menu
Mostrar la cita

no es dinamico, o sea, puede estar escrito todo en la web, solo me

ocuparia
Mostrar la cita

de ocultar aquellas opciones a las que el usuario no tiene acceso.

En este caso, la variable de session se podria reducir a practicamente

una,
Mostrar la cita

con un simple texto de IDs o algun tipo de identificado separado por ,

para
Mostrar la cita

saber que menus se le deben mostrar al usuario.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net - DCE3
"bajopalabra" escribió en el mensaje
news:
> gracias por la respuesta matías
>
> cada usuario
> puede estar habilitado para desempeñarse
> como varios perfiles distintos a la vez (entre 1 y 7)
>
> 10.000 usuarios tienen 1 solo perfil
> 100 usuarios tienen 2 perfiles
> menos de 10 tienen más de 2 perfiles
>
> yo guardaría en distintas variables de sesión
> si el usuario tiene el perfil habilitado , por ej:
>
> session("perfil_1")= true
> session("perfil_4")= true
>
> luego, las páginas enviadas se verían así, con dos links:
>
> | perfil 1 |
> | perfil 4 |
> - (esto sería un menú :-)
>
> ahora, dentro de "Perfil 1"
> debo crear dinámicamente un sub-menú "A, B, C"
> y eso ya depende de las cosas asociadas a cada usuario , no al perfil
> por lo que tendría que guardar arrays
> dentro de cada variable de sesión
>
> session("perfil_1") <-- rst_1.getrows( )
> session("perfil_4") <-- rst_4.getrows( )
>
> esto no sería problema para los últimos 110 usuarios (100 + 10)
> no involucra muchos recursos, y además
> son usuarios muy esporádicos
>
> EL PROBLEMA :
> es que estoy tratando de beneficiar a esos primeros 10.000
> armándoles también un sub-menú personalizado
>
> los 10.000 usuarios tendrían entre 1 y 4 opciones ;
> en promedio : 2,5 -- a 100 bytes c/u
>
> claro que no voy a tener 10.000 "usuarios concurrentes"
> la máxima cantidad de conexiones concurrentes reales
> históricamente fue de #10
>
> siendo muy pesimista, con 100 conexiones concurrentes tendría :
> 100 x 2,5 = 250 opciones de sub-menú x 100 bytes = 25.000 bytes
>
> aprox 25 KB
>
> (*) CUÁNTA memoria requiere iniciar cada una de las 100 sesiones ?
> me parece haber leido 10 KB c/u, es cierto ?
> eso haría un total de 25 KB + 1000KB = más o menos 1 MB
>
> espero haberme explicado bien
>
> antes de hacer las cuentas pensaba modificar
> la aplicación para ser session-less
>
> pero, si las cuentas salieron bien, le podría dar facilidades
> de acceso e interfaces más amigables a 11.000 usuarios
> con un costo de 1 MB + costo de cpu
> que es algo muy pero muy aceptable
>
> (*) qué opinión te merece el tener variables de sesión de 250 bytes ?
>
> por suerte, los sub-menúes no son un mero costo visual
> ya que contienen códigos
> para invocar directamente otras stored proc
> evitando hacer otras consultas para llegar a ellos
>
> atte, Hernán
>
> "Matías Iacono" escribió en el mensaje
> news:
>> Estas en lo correcto.
>>
>> Pero porque anular las sesiones por completo. El unico motivo valido
>> seria
>> el no tener la posibilidad de colocar cookies en el cliente, por lo que
> las
>> sessions no funcionarian.
>>
>> En el caso de que elimines las sessions por completo, no podrias

mantener
Mostrar la cita

>> informacion del usuario entre paginas, como podrias identificarlo? Si
>> usas
>> un cookie para almacenar informacion critica, este puede ser facilmente
>> modificable, y el usuario podria acceder a datos no permitidos.
>>
>> Posiblemente si vemos porque quieres no usar sessions, cual es la
> finalidad
>> de tu aplicacion web, podriamos encarar mejor el problema.
>>
>> Saludos.
>>
>> Matías Iacono
>> Microsoft MVP ASP/ASP.net - DCE3
>> "bajopalabra" escribió en el mensaje
>> news:
>> > además,
>> > me parece que antes de entregar cada página
>> > tendría que consultar si el "id de sesión" de la página
>> > (vía cookie, get o post) coinicide con el guardado
>> > en la tabla de "sesiones"
>> >
>> > teniendo que establecer una conexión nueva
>> > creando y liberando objetos ADO ...
>> >
>> > pero todo eso también es overhead
>> >
>> > por lo tanto me parece más costoso
>> > session-less que utilizar sesiones
>> > ya que con estado de sesion utiliza memoria y algo de cpu
>> >
>> > mientras que sin sesión (manteniendo el id con cookie/get/post)
>> > utilizará más cpu por validar sesión en cada página,
>> > más memoria ya que necesita establecer 2 conexiones más
>> > y utilizar objetos ADO con mucha frecuencia
>> > y además operaciones red y de Entrada/Salida contra la base de datos
>> >
>> > no te parece ?
>> > estoy errado ?
>> >
>> > atte, Hernán
>> >
>> > "Matías Iacono" escribió en el mensaje
>> > news:
>> >> Si trabajas con ASP 3.0, el manejo de session sin sessions debes
> hacerlo
>> > por
>> >> tu lado.
>> >>
>> >> Podrias tener una base de datos, para almacenar la informacion de

cada
Mostrar la cita

>> >> usuario. En la misma tabla, un campo de tipo hora para saber cuando
>> >> fue
>> >> la
>> >> ultima vez que ese usuario hizo un requerimiento. De esta manera,
> podrias
>> >> saber cuanto tiempo de inactividad ha pasado para ese usuario.
>> >>
>> >> Ademas, claro esta, que deberias tener un cookie o (en el caso de

que
Mostrar la cita

>> > esten
>> >> desabilitados) mantener el ID en la barra de navegaciones y
>> >> arrastrarlo
>> >> pagina a pagina, algo asi como hace .Net.
>> >>
>> >> Saludos.
>> >>
>> >> Matías Iacono
>> >> Microsoft MVP ASP/ASP.net - DCE3
>> >> "bajopalabra" escribió en el mensaje
>> >> news:
>> >> > hola
>> >> > si deshabilito las sesiones
>> >> > cómo identifico la sesión de un usuario ?
>> >> >
>> >> > suponiendo, que genero mi propio "id de sesión" para cada login
>> >> > (el que arrastro por cada página del sitio para no perderlo)
>> >> > cómo puedo, luego, saber que una sesión ha terminado ?
>> >> > recuerdo que el evento Session_OnEnd( ) no siempre funciona

bien..
Mostrar la cita

>> >> >
>> >> > atte, Hernán
>> >> >
>> >> > atte, Hernán
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Pues te haz tomado el trabajo!! :D

Con que base de datos trabajas?

Te pregunto esto, debido a que, personalmente, conseguiria mayor desempeño
sacando los datos en el momento de necesitarlos. Si tu aplicacion lo
permite, podrias tener un frame para este menu, para que solo sea cargado
una vez, y recargas la DB solo esa vez.

Otra alternativa seria tener las variables session normales, pero si el menu
no es dinamico, o sea, puede estar escrito todo en la web, solo me ocuparia
de ocultar aquellas opciones a las que el usuario no tiene acceso.

En este caso, la variable de session se podria reducir a practicamente una,
con un simple texto de IDs o algun tipo de identificado separado por , para
saber que menus se le deben mostrar al usuario.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net - DCE3
"bajopalabra" escribió en el mensaje
news:
Mostrar la cita

gracias por la respuesta matías

cada usuario
puede estar habilitado para desempeñarse
como varios perfiles distintos a la vez (entre 1 y 7)

10.000 usuarios tienen 1 solo perfil
100 usuarios tienen 2 perfiles
menos de 10 tienen más de 2 perfiles

yo guardaría en distintas variables de sesión
si el usuario tiene el perfil habilitado , por ej:

session("perfil_1")= true
session("perfil_4")= true

luego, las páginas enviadas se verían así, con dos links:

| perfil 1 |
| perfil 4 |
- (esto sería un menú :-)

ahora, dentro de "Perfil 1"
debo crear dinámicamente un sub-menú "A, B, C"
y eso ya depende de las cosas asociadas a cada usuario , no al perfil
por lo que tendría que guardar arrays
dentro de cada variable de sesión

session("perfil_1") <-- rst_1.getrows( )
session("perfil_4") <-- rst_4.getrows( )

esto no sería problema para los últimos 110 usuarios (100 + 10)
no involucra muchos recursos, y además
son usuarios muy esporádicos

EL PROBLEMA :
es que estoy tratando de beneficiar a esos primeros 10.000
armándoles también un sub-menú personalizado

los 10.000 usuarios tendrían entre 1 y 4 opciones ;
en promedio : 2,5 -- a 100 bytes c/u

claro que no voy a tener 10.000 "usuarios concurrentes"
la máxima cantidad de conexiones concurrentes reales
históricamente fue de #10

siendo muy pesimista, con 100 conexiones concurrentes tendría :
100 x 2,5 = 250 opciones de sub-menú x 100 bytes = 25.000 bytes

aprox 25 KB

(*) CUÁNTA memoria requiere iniciar cada una de las 100 sesiones ?
me parece haber leido 10 KB c/u, es cierto ?
eso haría un total de 25 KB + 1000KB = más o menos 1 MB

espero haberme explicado bien

antes de hacer las cuentas pensaba modificar
la aplicación para ser session-less

pero, si las cuentas salieron bien, le podría dar facilidades
de acceso e interfaces más amigables a 11.000 usuarios
con un costo de 1 MB + costo de cpu
que es algo muy pero muy aceptable

(*) qué opinión te merece el tener variables de sesión de 250 bytes ?

por suerte, los sub-menúes no son un mero costo visual
ya que contienen códigos
para invocar directamente otras stored proc
evitando hacer otras consultas para llegar a ellos

atte, Hernán

"Matías Iacono" escribió en el mensaje
news:
Mostrar la cita

Estas en lo correcto.

Pero porque anular las sesiones por completo. El unico motivo valido
seria
el no tener la posibilidad de colocar cookies en el cliente, por lo que

las
Mostrar la cita

sessions no funcionarian.

En el caso de que elimines las sessions por completo, no podrias mantener
informacion del usuario entre paginas, como podrias identificarlo? Si
usas
un cookie para almacenar informacion critica, este puede ser facilmente
modificable, y el usuario podria acceder a datos no permitidos.

Posiblemente si vemos porque quieres no usar sessions, cual es la

finalidad
Mostrar la cita

de tu aplicacion web, podriamos encarar mejor el problema.

Saludos.

Matías Iacono
Microsoft MVP ASP/ASP.net - DCE3
"bajopalabra" escribió en el mensaje
news:
> además,
> me parece que antes de entregar cada página
> tendría que consultar si el "id de sesión" de la página
> (vía cookie, get o post) coinicide con el guardado
> en la tabla de "sesiones"
>
> teniendo que establecer una conexión nueva
> creando y liberando objetos ADO ...
>
> pero todo eso también es overhead
>
> por lo tanto me parece más costoso
> session-less que utilizar sesiones
> ya que con estado de sesion utiliza memoria y algo de cpu
>
> mientras que sin sesión (manteniendo el id con cookie/get/post)
> utilizará más cpu por validar sesión en cada página,
> más memoria ya que necesita establecer 2 conexiones más
> y utilizar objetos ADO con mucha frecuencia
> y además operaciones red y de Entrada/Salida contra la base de datos
>
> no te parece ?
> estoy errado ?
>
> atte, Hernán
>
> "Matías Iacono" escribió en el mensaje
> news:
>> Si trabajas con ASP 3.0, el manejo de session sin sessions debes

hacerlo
Mostrar la cita

> por
>> tu lado.
>>
>> Podrias tener una base de datos, para almacenar la informacion de cada
>> usuario. En la misma tabla, un campo de tipo hora para saber cuando
>> fue
>> la
>> ultima vez que ese usuario hizo un requerimiento. De esta manera,

podrias
Mostrar la cita

>> saber cuanto tiempo de inactividad ha pasado para ese usuario.
>>
>> Ademas, claro esta, que deberias tener un cookie o (en el caso de que
> esten
>> desabilitados) mantener el ID en la barra de navegaciones y
>> arrastrarlo
>> pagina a pagina, algo asi como hace .Net.
>>
>> Saludos.
>>
>> Matías Iacono
>> Microsoft MVP ASP/ASP.net - DCE3
>> "bajopalabra" escribió en el mensaje
>> news:
>> > hola
>> > si deshabilito las sesiones
>> > cómo identifico la sesión de un usuario ?
>> >
>> > suponiendo, que genero mi propio "id de sesión" para cada login
>> > (el que arrastro por cada página del sitio para no perderlo)
>> > cómo puedo, luego, saber que una sesión ha terminado ?
>> > recuerdo que el evento Session_OnEnd( ) no siempre funciona bien..
>> >
>> > atte, Hernán
>> >
>> > atte, Hernán
>> >
>> >
>>
>>
>
>