🚀 go-pugleaf

Pere Vilas wrote:
> 
> Tener m�ltiples clientes corriendo en su propio thread y otro que gestiona
> sus eventos puede tener una aplicaci�n pr�ctica aunque creo que no acaba de
> ser legal. 

Yo no lo veo as�. El hecho de que tienes un thread que mantiene una cola
de eventos no descarta la posibilidad de que las peticiones se atiendan
luego de modo m�s sofisticado. Es decir, ese thread que lee la cola de
eventos puede perfectamente engendrar otros threads a su vez para hacer
el trabajo. Y despu�s puedes tener toda una l�gica de acceso
sincronizado a los recursos etcetera.

Como dije, ha habido mucha inversi�n de esfuerzo en este dominio, es
todo el tema de middleware etcetera.

> El thread gestor de eventos(el consumidor) de alguna forma est�
> serializando las peticiones de los clientes (obliga a que se ejecuten una
> detr�s de otra). Por lo tanto, con una sola conexi�n a una base de datos
> podemos responder a m�ltiples clientes. Vendr�a a ser como una multiplexi�n
> de la conexi�n. Sin embargo, para hacerlo bien, cada cliente ha de poder
> iniciar y acabar una transacci�n, de ah� el inter�s.

S�, pero el hecho en s� de que tienes una cola principal de eventos
corriendo en un thread no descarta todas esas posibilidades.

Jonathan Revusky
-- 
Available for Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions