Deseo crear una página JSP seguro para subprocesos. Es posible en Servlet implementando la interfaz SingleThreadModel, pero no sé cómo hacerlo en la página JSP.Cómo puedo crear la página JSP seguro para subprocesos
Teóricamente, las páginas JSP pueden indicarse como threadsafe mediante el atributo de directiva de página isThreadSafe. Al establecer un valor de falso, el contenedor sincronizará el acceso a los objetos de nivel de página (y no a objetos de sesión u objetos de ámbito de aplicación u objetos de cualquier otra variedad). Obviamente, sigue siendo responsabilidad del desarrollador garantizar el acceso sincrónico para enhebrar regiones de código inseguras.
Además, la interfaz SingleThreadModel también se ha desaprobado en la versión 2.4 de la especificación del servlet. La interfaz SingleThreadModel también se usa para implementar la supuesta seguridad de subprocesos en JSP: las clases de servlet generadas implementarán SingleThreadModel para JSP que utilizan el atributo de subprocesos. La especificación en sí explica por qué la interfaz está en desuso:
SRV.2.2.1 nota sobre el Modelo único hilo
el uso de los SingleThreadModel interfaz garantiza que sólo una hilo a la vez lo hará ejecutar en un servicio dado de la instancia servlet método. Es importante tener en cuenta que esta garantía solo se aplica a cada instancia de servlet , ya que el contenedor puede optar por agrupar dichos objetos. objetos que son accesibles a más de una instancia servlet en un momento, tales como casos de HttpSession, pueden estar disponible en cualquier momento en particular a múltiples servlets, incluidos los que implementan SingleThreadModel.
Se recomienda que un desarrollador tomar otros medios para resolver esos problemas en lugar de implementar esta interfaz , tales como evitar el uso de una variable de instancia o sincronizar el bloque del código acceder a esos recursos. La interfaz SingleThreadModel es obsoleta en esta versión de la especificación .
Pensé que SingleThreadModel estaba en desuso en las 2.5 especificaciones. – naikus
No es así.
JSP es básicamente un único método en un servlet. Como ya sabrá, los métodos son seguros para subprocesos, el sentido de que dos subprocesos que invocan el mismo método del mismo objeto al mismo tiempo ejecutarán cada uno en su propia pila.
Por lo tanto, realmente no necesita hacer un JSP seguro para hilos, porque ya es seguro.
Si declara una variable a en un JSP, no hay forma, otra solicitud ve esa variable.
Lo que debe tener en cuenta, es que los objetos se colocan en la sesión, o se puede acceder al contexto mediante varios subprocesos al mismo tiempo, o casi no es un código seguro. ¡Entonces lo que debe sincronizar o cuidar es esos objetos!, y no la página JSP en sí misma.
Hablar de seguridad de hilos con JSP es incorrecto: JSP es una tecnología de visualización y solo muestra resultados, no procesa nada. (Que puede hacer el proceso, pero no debe)
rosca con la seguridad con los servlets se consigue teniendo no campos privados en el servlet - la instancia del servlet es una para todo el envase y cada solicitud es un nuevo thread invocando el método service(..).
Debe especificar exactamente lo que quiere decir con "hilo de seguridad" en su caso, es decir, qué espera fallar.
Al no tener ninguna información de estado en su página JSP. (No variables de instancia, que pueden cambiar entre diferentes solicitudes). Si usted no tiene ningún estado en su JSP o servlet, que son multi-hilo Primero la respuesta corta < página
% @% isThreadSafe = "false">
La respuesta larga es no hacer eso.
Debe tener muy claro su objetivo aquí. No ha hecho que un servlet sea realmente seguro para subprocesos mediante el uso de SingleThreadModel, sino que ha configurado las cosas para que solo un subproceso a la vez pueda acceder a su servlet. Presumiblemente, usted estaría haciendo eso exactamente porque el código del Servlet es no hilo seguro, es decir, si más de un hilo fuera a llegar al código, pasarían cosas malas.
Esto implica para mí que usted tiene algo como esto en el código del servlet:
doGet(/*etc/*){
// ... stuff
someExistingUnsafeClass.doSomething();
// .. more stuff
}
Después de todo, su código serlvet sí misma no puede ser flujos insegura, ¿verdad? Lo arreglarías, ¿verdad? ¿Entonces debe ser algún código heredado que no sea seguro?
Si este es el escenario, con su JSP necesidad de utilizar ese código heredado existente, en algún lugar de su JSP tiene una llamada de ese material peligroso:
<%
someExistingUnsafeClass.doSomething();
%>
lo que sólo necesita para proteger esta llamada insegura:
<%
synchronized(this){
someExistingUnsafeClass.doSomething();
};
%>
Permitir que la mayor parte de su JSP funcione correctamente enhebrado funcionará mucho mejor.
También debería decir que si estructura su aplicación como MVC, entonces se llamará a todos los códigos de seguridad de subprocesos desde el controlador y la vista (el JSP) nunca debe ser insegura.
En JSP, solo use variables en los scriplets y puede estar seguro de que son seguros para subprocesos porque se traducirán a la variable local en service().
No deberías hacer. Si lo hace, significa que su diseño es totalmente defectuoso. Serás despedido en el olvido cuando lo estés haciendo en el mundo real de los negocios. Consulte también [Servlets and Threadsafety] (http://stackoverflow.com/questions/3106909) y [Cómo evitar el código de Java en JSP] (http://stackoverflow.com/questions/3177733). – BalusC