Egy kapcsolat medence tomcat
Ma már nehéz elképzelni, hogy egy webes alkalmazás, amely nem használja az adatbázist az igényeiknek. Amikor dolgozik az adatbázis nagyon fontos, hogy figyelemmel kíséri a kapcsolatot az adatbázissal, és engedje őket időben. Erre a célra egy webes alkalmazás fejlesztők írja az úgynevezett Connection Medencék (vagy / fix meglévőket).
Az egyik legjobb servlet konténer Apache Tomcat. Tomcat jól az a tény, hogy ő használja a saját DBCP (Database Connection Pool).
Konfigurálása Tomcat az alap, szükség van a konfigurációs fale conf \ server.xml a Context részeit (ha nincs szükség létrehozni a fogadó rész csak a vége előtt), adjuk hozzá a következő sorokat:
Ezzel a konfigurációval, akkor hozzon létre egy adatforrást nevű newDB. Tekintsük a paraméterek az objektum.
Paraméter gyári mondja, amit a gyárban kell használni, hogy hozzon létre objektumokat, amelyek megfelelnek a adatforrás interfészt. A következő paraméter az URL hozzáférni az adatbázishoz. A felhasználónév és jelszó, illetve tartalmazzák a felhasználónév / jelszó rendszereket és. Az adatbázis neve meghajtó meghatározott driverClassName paramétert.
Az alábbi paraméterek közvetlenül felelős a Connection Pool. Tekintsük őket egy kicsit.
maxActive - a kapcsolatok maximális számát, amely tartalmazni fogja a medencében. Ha ez a paraméter értéke 0, akkor a korlátozásokat a kapcsolatok száma az adatbázis nem lesz. A legtöbb adatbázis-kiszolgáló konfigurációja Dunn ezt a lehetőséget is létezik. Azt hiszem, nem kell magyarázni, hogy miért nagyobbnak kell lennie, mint maxActive.
maxIdle - a maximális száma inaktív kapcsolatokat, hogy marad a medencében. Ha ez a paraméter értéke nulla, nem fog korlátozás.
maxWait - ha a kapcsolat várakozási idő meghaladja maxWait paramétert (ezredmásodpercben), a felhasználó kap egy kivétel. Ha az érték -1, annál maxWait, a várakozási idő nincs korlátozva.
Megkérdezhetem rajz a figyelmet a következő nagyon fontos dolog. Tomcat fut egy virtuális gép (JVM). Ahhoz, hogy felszabadítsuk a JVM memória használ szemétgyűjtő (szemétgyűjtő). GC nagyon magas prioritást élvez, és a felszabadulás Tomcat memória megy be készenléti állapotban (in a másodperc tört része, legalábbis - pár másodperc). A kis értékei maxWait, a kapcsolat nem hozható létre, mivel a timeout. Az érték 10.000 legtöbb esetben lesz optimális.
removeAbandoned - ha telepíti ezt Parameres igaz, az elhagyott vegyület szabadul fel, amikor a számos ingyenes kapcsolatok a medence kicsi.
removeAbandonedTimeout - Ez a paraméter az idő másodpercben, amely után minden tétlen kapcsolat tekinteni.
Ezt követően, akkor be kell állítania a webes alkalmazás dolgozni adatforrás. Ez azért történik így, hogy a fájl-leíró web.xml write:
Végül, van, hogy minden vyshenapisannogo a gyakorlatban. Ahhoz, hogy hozzáférést biztosít a JNDI adatforrás keresztül, és adatbázis-kapcsolat létrehozására, írhat egyfajta osztály (csomag import és hibakezelés elhagyható):
Elhagyott vegyületek - egy feltételes kifejezés. Tomcat kijelöli a kapcsolat, mint elhagyott jelentőségteljesen removeAbandonedTimeout paramétert. Ez készült ezekből a megfontolásokból, hogy bizonyos helyzetekben, inaktív kapcsolatokat hatására hibás működését a program (hiba). Ezért szükséges, hogy legalább bizonyos mértékig képes követni, és hogy kiadja ezt a fajta kapcsolat.
A címke lehetővé teszi, hogy meghatározza a hitelesítési mód, amikor megpróbál kapcsolatot létesíteni az adatbázissal.
Az érték «Container» azt mondja, hogy elvégzi a hitelesítés alapján a tartály azonosítóját és jelszavát adott neki (vagy tanúsítvány) a felhasználó (például felhasználói adatokat adtak meg a leíró a kiválasztott kapcsolat medence DBMS). Egy másik lehetséges értelmében - «Application» - azt mondja, hogy a felhasználói beállítások világosan fel kell tüntetni a Java-kód szintű elérésekor a kapcsolat gyár a DBMS.
Azt, hogy valami gond:
1. Tomcat csak létrehozza források felhasználásával növények, ebben az esetben a kapcsolat a medence. De véleményem szerint ő nem tudják kezelni a zhizennye ciklus, vagyis, hogy nem érdekli a helyes megszüntetése. Meg kell regisztrálni a hallgatót server.xml szerver életciklusa, amely elzárja a medencében.
2. A medence regisztrált server.xml, ahelyett, vitatja a kérelmet, ha szándékában megosztani a vele egy pár alkalmazást, akkor tartózkodni kell a:
2.1 Szivárgás kapcsolatok egyetlen alkalmazás, kiléphet a rendszerből, más alkalmazás használja a medencét.
2.2 Talán nehéz lenne pontosan meghatározni, hogy melyik alkalmazás szivárog, vagy hány csak nem egy adott alkalmazás összefüggéseit.