[Java lista] connection pool MySQL Hibernate Tomcat

[info@e-dog.hu]

Halihó!

Köszönöm a választ!


>>  Szerintetek?  Vagy hol találok erről valamit is. Már rengeteget gugliztam!
>>     
>  Szerintem. Filter kellene. Filter végezze az azonosítást. Elég egy kapcsolat 
> is akár, de lehet szedni pool-ból a filter belépő pontján, majd a végén 



Végül is a felhasználó azonosítás az container alapú, az jó is így mert a felhasználóhoz 
több felhasználói adatbázis is kapcsolódhat abból kell választania. Van is erre egy filter 
mely visszadobja ide a felhasználót ha még nem választott.



> > Kell egy olyan szerkezet, hogy ki és mikor kérte el utoljára a kapcsolatot. 
> > Ha jön a user és még nincs benne a listában, akkor kap egy bejegyzést, 
> > létrehozod a db kapcsolatot, majd átadod neki, akár a request-en át, 
> > tökmindegy. Ha jön újabb user, akkor szintén. Ha régi user jön, akkor 
> > frissíteni kell azt a bejegyzést, hogy mikor kérte el a kapcsolatot, és 
> > odaadni a kapcsolatot. Néha meg kell nézni a listát, és a túl régi 
> > kapcsolatokat kivenni, lezárni és törölni a listáról.
>   

De lényegében nem ez a connection pool? Tegnap átfutottam a 
Apress-es Beginning Hibernate From novice to Professional idevonatkozó részét. És abból azt olvastam ki, 
hogy  Session olyan mint a connection és a SessionFactory pedig olyan mint a ConnectionPool 
ha a JDBC-vel hasonlítjuk össze.
Meg a SessionFactory az szálbiztos, a Session pedig nem. SessionFactory drága a Session pedig nem. 
Nyilván a Session az sokkal több mert abban ott vannak az objektumaim állapotaikkal együtt ..... 

Tehát a HibernateUtil Singleton -ba kell előkészíteni az összes SessionFactory-t, és mindig az adom 
vissza amelyik kell nyilván vanegy fix.... 
Csak ez a SessionFactory mennyit kajol memoriából.  

Nyilván ha lenne több párhuzamos felhasználó mint amennyi adatbázis akkor már jobban is jártunk. 
Csak még most ez nem igaz...   


GeZo