Los Threads y la sincronizaci�n se explicaron en la lecci�n Miscel�nea. Esta secci�n describe en general los problemas que el desarrollador de proveedores de servicio podr�an encontrar con respecto al acceso multi-thread y el uso de los threads en los proveedores de servicio.
�Implementaciones de Contexto
El JNDI define el interface Context y sus subinterfaces con los que se debe implementar un proveedor de servicio. La seguridad de los threads con respecto al acceso concurrente es un problema de implementaci�n. Sin embargo, el JNDI hace algunas recomendaciones de sentido com�n sobre lo que el usuario del API y el proveedor de servicio deber�an esperar:
- El acceso a un s�lo ejemplar de Context debe estar sincronizado.
- Los accesos a ejemplares Context separados no tienen que estar sincronizados, incluso cuando esos ejemplares de Context est�n relacionados.
La primera regla significa que el proveedor de servicio no tiene que preocuparse de proteger los accesos a los recursos usados por un s�lo ejemplar de Context contra accesos concurrentes multi-thread. Los llamadores son responsables de sincronizar sus accesos entre ellos mismos. Esta regla permite a las implementaciones de contexto ser optimizadas para su modo de uso de threads m�s com�n.
La segunda regla recuerda a los escritores de proveedores de servicio que cuando los ejemplares de Context de la misma implementaci�n de contexto comparten recursos, esos recursos deben protegerse contra accesos concurrentes. Por ejemplo, varios ejemplares de Context normalmente comparten la misma conexi�n de red subyacente. En este caso deber�amos proteger a la conexi�n de red contra accesos concurrentes. Esta regla est� motivada por el hehco de que los llamadores no pueden tener cuidado de ninguna relaci�n subyacente entre diferentes ejemplares de Context y seguramente no podr�n sincronizar sus accesos a diferentes ejemplares de Context. Por lo tanto el proveedor de servicio debe asegurarse que diferentes ejemplares Context se comportan como entidades individuales e independientes y ocultan cualquier relaci�n.
�Implementaciones de Factor�as
Un objeto que implemente cualquiera de los siguiente interfaces y clases abstractas (y sus subinterfaces) debe ser re-entrante. Es decir, varios threas deber�an poder llamar a m�todos de un s�lo ejemplar de una factor�a concurrentemente.
La mayor�a de las factor�as no tienen estado, por eso este requerimiento de re-entrada no es mucho m�s que una imposici�n de la implementaci�n.
�Uso de Threads
Los threads son herramientas �tiles para construir sistemas de software como una implementaci�n de contexto, especialmente cuando la implementaci�n necesita tratar con la red. De hecho, los threads son indispensables si una implementaci�n de contexto va a soportar notificaci�n de eventos como se describi� en el paquete javax.naming.event (ver la lecci�n Notificaci�n de Eventos).
Podr�amos usar threads cuando construyamos los componentes de un proveedor de servicio. Sin embargo, debemos tener cuidado ya que la plataforma Java 2 Platform, Enterprise Edition, restringe componentes como los Enterprise JavaBeans de crear threads. Esta restricci�n significa que si nuestro proveedor de servicio necesita crear threads deber�a hacerlo dentro de un bloque doPrivileged. Esto permite al contenedor del componente conceder el permiso para que el proveedor de servicio cree un thread sin concederselo al componente.
Aqu� tenemos un ejemplo de un m�todo de utilidad que realiza la creaci�n de un thread dentro de un bloquedoPrivileged:
private Thread createThread(final Runnable r) {
return (Thread) AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
return new Thread(r);
}
}
);
}