Servlets, EJB (Pregunta enredada)

[Machine80]

Hola nuevamente. Mi consulta va relacionado con lo siguiente:

Abrir desde varias ventanas de navegadores (en el mismo computador) instancias distintas del mismo servlets para cada navegador. Según las pruebas que he hecho, si dos navegadores llaman al mismo servlet (<form action=/servlet1 ...) no se crea una instanca para cada ventana, si no que se crea UNA sola instancia de Servlet1 para ambos, compartiendo variables ya inicializadas. (Ojo que en el mismo computador)

Porqué necesito esto? necesito diferenciar distintos servlets, ya que éstos actuan como clientes para los EJB. Las sesiones las quiero manejar con EJB session y no con sesiones HttpSession en cada servlets. Obviamente nesesito manejar distintos EJB para cada navegador, (aunque estén en el mismo computador)


Entonces quiero saber si estoy bien enfocado con lo que estoy haciendo o se debe pensar de otra forma. O si necesariamente hay que usar HttpSession para diferenciar datos en cada servlet. Y si fuera necesario usar HttpSession, ¿Como puedo diferenciar cada instancia del mismo servlet para que los EJB sepan que son instancias distintas?, o sea, se creen instancias dstintas de un EJB session por cada instancia del sevlet?


Helpmeeeee
(Quizás me esté ahogando en un vaso con agua, glup, glup. glup!!!!)

[hugo777]

Hola Machine80, veamos si puedo explicarte sin que nos enredemos ambos ....

Los servlets crean una SOLA INSTANCIA, y esta se dedica a atender a todos los request/response que reciba. Por lo tanto por más que tu quieras no podrás tener más de una instancia para un servlet, ya que el WebContainer se encargará de prevenir ello.
Si tu necesitas tener dos instancias de serlvets y que sean distintas, entonces, crea 2 servlets, cada uno con diferente nombre. Para que así sean clases distintas y por lo tanto serán instancias distintas.

Los EJB efectivamente puede manejar la sesion, pero creo que aquí te estas confundiendo con el nombre, porque los "EJB Session" pueden ser de dos tipos:
SIN ESTADO (stateless) es decir que no recuerdan los datos entre request y request, y CON ESTADO (statefull) es decir que si recuerdan los datos entre request y request. Por lo tanto decir que utilizas EJB Session, no significa que trabajen con la sesión, ni que recuerden los datos necesariamente, porque esto dependerá del tipo de EJB Session que utilices.
Sólo los EJB Session Satefull pueden mantener datos en sesión y recordarlos, sin embargo, la recomendación del estándar JAVA están en dejar de usar los EJB Session Staefull y utilizar el HttpSession. Ya que, es mucho más pesado y complicado manejar la sesión en el EJB Container con los EJB Session Statefull, por lo que es mejor utilizar el HTTPSESSION tradicional de los WebContainer.

Las instancias de EJB Session son manejadas por el EJB Container, por lo tanto tu no tienes el control de crear y/o utilizar instancias particulares. Será el EJB Container el que te dará una referencia a una instancia libre en ese momento y que pueda atenderte. Entonces crear una instancia de un mismo EJB, depende del EJB Container, y sólo se dará si el acceso concurrente a este lo exige y el pool configurado para el EJB lo permite.
Ahora, si nuevamente aquí quieres tener otra instancia de un EJB, pues no depende de tí, sino del EJBContainer, que hacer entonces? pues lo mismo que para los servlets,crea otro EJB que sea llamado desde tu sengundo servlet, y así vas a tener con toda seguridad DOS CAMINOS distintos.

Recuerda que no estas en un entorno libre de crear instancias y destruirlas, sino que estas supeditado a los WebContainer y EJB Container, que entre otras cosas ellos tiene el control de crear, destruir, activar, pasivar, ejecutar los objetos JAVA (servlets o EJBs) dentro de su entorno.

Espero haya quedado más claro?, si tienes alguno duda hazla ...

[Machine80]

ok, mi idea era usar EJB Statefull, pero si se recomienda usar httpSession lo hago así (para estar al día).

Resumiendo: Mi idea original era utilizar EJB Statefull sin httpSession, con servlets que fueran los clientes

Ahora usaré httpSession con EJB stateless, y "creo" que se me solucionan todos los problemas. La idea de usar EJB Statefull era dejar las sesiones independientes del cliente que se conecte (en este caso el servlet) por si después se quisiera implementar otro tipo de cliente (swing o algo así) ya tuviera las sesiones implementadas.

Gracias, si tengo más consultas, lo mas seguro es que aparezcan por aqui, chao

[goncafa]

Hola, solo aclarar algo, si bien lo que te dice hugo es correcto, en cuanto a que todas las instancias comparten una misma clase instanciada, y por tanto sus variables y todo, esto es por defecto, pero si en determinado caso, quicieramos que esto no sea asi, es decir, que cada peticion tenga su propia instancia a la clase por separado, y por ende no comparten nada, solo debemos implementa la interfaz

SingleThreadModel

Esta interfaz no tiene ningun metodo, por tanto no debemos implementar nada especial, basta con hacer esto

Código PHP:

  public class MiServlet extends HttpServlet implements SingleThreadModel { 
 
}  
   

solo agregando la linea implements SigleThreadModel a la definicion del servlet este ya no hara que las peticiones compartan instancias de la misma clase.

OJO: esto solo hazlo cuando sea necesario, pues la velocidad de respuesta y podrian bajar considerablemente.

Saludos

[hugo777]

Hola, asi es goncafa, SingleThreadModel, en realidad lo que hace es que "SOLO UN HILO PUEDE ACCEDER AL SERVLET A LA VEZ" (como si estuviera protegido por syncronizhed), por lo tanto, eso siginifica que sólo un request podría ser atendido a la vez, y lo que se lograría es EVITAR que como varios pueden trabajar con el servlet a la vez, ya no compartirían nada.

Pero lo que si, no puede lograrse es crear más de una instancia para un servlet. Si bien el SingleThreadModel nos simula un efecto parecido, en el fondo no se puede hacer que exista dos instancias (objetos) del mismo servlet dentro del webcontainer.

[goncafa]

En realidad si, SigleThreadModel lo que hace es exactamente que puedan muchos estar accediendo al servlets, pero cada uno con una instancia a este diferente, haz la prueba y ya veras

Por ejemplo, fijate en este texto que extraje directamente de la documentacion de la API:

Note that SingleThreadModel does not solve all thread safety issues. For example, session attributes and static variables can still be accessed by multiple requests on multiple threads at the same time

Eso dice claramente, que esta interfaze no separa todo en diferentes hilos, y que por ejemplo, las variables estaticas y las de session pueden ser accedidas por diferentes hilos al mismo tiempo.

Es decir, que si se estan ejecutando diferentes instancias de la clase

Saludos

[hugo777]

hummmm, creo que hay una confusión goncafa, y es que decir que se tiene multiples hilos, no lo mismo que decir múltiples instancias...

Un hilo es un proceso ligero de ejecución, mientras que una instancia es un objeto cargado en memoria para una clase determinada en JAVA.

En SERVLETS, existe una sóla instancia, y ella puede atender a múltiples hilos a la vez. Es por eso que cuando tu tienes tu aplicación web desde internet, tienes tu servlet y varias usuarios concurrentes pueden acceder, pero comparten los datos, debido a que es una sóla instancia, es como si fueran variables estáticas.
Entonces cuando tu le pones SingleThreadModel a un servlet, le dices que no atienda a varios hilos, sino a uno, pero en fondo, siempre sigue siendo una instacia.

Esta mas claro ahora?

[goncafa]

Pues no, la confucion esta en que cuando implementas SigleThreadModel esto se comporta como si fuese por ejemplo una pagina PHP o ASP, es decir, claro, todos estan instanciando el mismo programa, la misma pagina, este caso, el mismo Servlets, pero este ya no hace compartir todas las peticiones en diferentes subprocesoso como lo hacen los Servlets por defecto, sino que cada uno tiene su proceso por separado, y perfectamente pueden haber muchos viendo el Servlets al mismo tiempo, solo que ya no comparten los datos, solo las variables estaticas, pero ese es un comportamiento nativo de Java, no es algo de los Servlets, pues las variables estaticas siempre se han compartido por los diferentes objetos que tengan instancias de la misma clase.

Saludos

[hugo777]

Ok goncafa, mira leyendo la documentación oficial de SingleThreadModel:

http://java.sun.com/j2ee/sdk_1.3/tec...readModel.html

Se menciona que, lo que se previene que un sólo hilo ejecute a la vez sólo el método SERVICE, y que tienes DOS FORMAS de hacerlo, la primera es como yo te comentaba, manteniendo una sólo inatancia y aplicando el SYNCHRONIZED y la SEGUNDA FORMA, es la que tu mencionas, es decir tener varias instancias, y aplicando la independencia de cada una de ellas.
Ante, esto me viene la pregunta, como aplicar una forma y otra forma, porque si bien, tienen el mismo efecto, en el fondo son distintas, y tienes consumos distintos de recursos.


Ensures that servlets handle only one request at a time. This interface has no methods.
If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.

Gracias por la aclaración.

[goncafa]

Pues vaya
de hecho es cierto lo que nombras, pero en todos los libros que he leido dice lo que yo te he dicho... y almenos por mi parte cuando lo he aplicado a funcionado asi... mmmmmm kiza alla que seguir averiguando verdad??

Gracias y Saludos