Setări pool de conexiuni

Utilizaţi această pagină pentru a configura setările pool de conexiuni.

Această pagină consolă administrativă este comună cu sursele de date JDBC şi fabricile de conexiuni JMS (fabrici de conexiuni unificate, coadă sau subiect). Pentru a vizualiza această pagină, calea depinde de tipul resursei, dar în general selectaţi o instanţă a tipului de resurse apoi faceţi clic pe Pool de conexiuni. De exemplu:
Evitare probleme: Pooling-ul de conexiuni nu este suportat într-un client de aplicaţii. Clientul de aplicaţii apelează baza de date direct şi nu trece printr-o sursă de date. Dacă vreţi să utilizaţi cererea getConnection() de la clientul de aplicaţii, configuraţi furnizorul JDBC în descriptorii de implementare client de aplicaţii, utilizând Dezvoltatorul de aplicaţii Rational sau o unealtă de asamblare. Conexiunea este stabilită între clientul de aplicaţii şi baza de date. Clienţii de aplicaţie nu au un pool de conexiuni, dar puteţi configura setările furnizor JDBC în descriptorii de implementare client.gotcha
Timeout de conexiune

Specifică intervalul, în secunde, după care o cerere de conexiune expiră şi ConnectionWaitTimeoutException este aruncată.

Această valoare indică numărul de secunde pe care o cerere de conexiune îl aşteaptă când nu sunt conexiuni disponibile în pool-ul liber şi nicio conexiune nouă nu poate fi creată.Aceasta apare de obicei deoarece valoarea maximă a conexiunilor din pool-ul de conexiuni particular a fost ajuns.

De exemplu, dacă Timeout-ul de conexiune este setat la 300, şi numărul maxim de conxiuni sunt toate în utilizare, manager de pool aşteaptă 300 de secunde o conexiune fizică pentru a deveni disponibil. Dacă o conexiune fizică nu este disponibilă în timpul acestei perioade de timp, managerul de pool iniţiază o excepţie ConnectionWaitTimeout. În cele mai multe cazuri ar trebui să nu reîncercaţi metoda getConnection(); dacă un timp de aşteptare mai lung este necesar ar trebui să creşteţi valoarea setării Timeout de conexiune. Dacă o excepţie ConnectionWaitTimeout este prinsă de către aplicaţie, examinaţi utilizarea pool-ului de conexiuni aşteptat al aplicaţiei şi ajustaţi pool-ul şi baza de date a conexiunii în concordanţă.

Dacă Timeout-ul conexiune este setat la 0, managerul de pool aşteaptă cât este necesar până când o conexiune devine disponibilă. Aceasta se întâmplă când aplicaţia termină o tranzacţie şi întoarce o conexiune la pool, sau când numărul de conexiuni scade sub valoriea Conexiuni maxime, permiţând ca o nouă conexiune fizică să fie creată.

Dacă Conexiunile maxime sunt setate la 0, care activează un număr infinit de conexiuni fizice, atunci valoarea Timeout-ului conexiune este ignorată.

Tip date Întreg
Unităţi Secunde
Implicit 180
Interval 0 la max int
Conexiuni maxime

Specifică numărul maxim de conexiuni fizice pe care le puteţi crea în acest pool.

Acestea sunt conexiunile fizice de la resursa de back-end. O dată ce acest număr este ajuns, nicio conexiune fizică nouă nu este creată şi solicitantul aşteaptă până când o conexiune fizică care este în mod curent în utilizare se întoarce la pool, sau până când ConnectionWaitTimeoutException este aruncată. De exemplu: Dacă valoarea Conexiuni maxime este setată la 5, şi există cinci conexiuni fizice în utilizare, managerul de pool aşteaptă durata specificată în Timeout-ul de conexiune pentru ca o conexiune fizică să devină liberă.

Cunoscând numărul de pool-uri de conexiuni care pot în mod potenţial să ceară conexiuni de la back-end (cum ar fi baza de date DB2 sau un server CICS) vă ajută să determinaţi o valoare pentru proprietatea Conexiuni maxime.

[AIX Solaris HP-UX Linux Windows] [iSeries] Pentru servere de aplicaţii autonome multiple care folosesc aceeaşi configuraţie surse de date, sau configuraţia fabrică de conexiuni J2C, un pool de conexiuni fizice separat există pentru fiecare server. Dacă clonaţi aceste aceleaşi servere de aplicaţii, Serverul de aplicaţii WebSphere implementează un pool de conexiune separat pentru fiecare clonă.

[z/OS] Consideraţi numărul de funcţionari care accesează aceeaşi resursă; la runtime, acest număr în mod esenţial vă multiplică setarea Conexiuni maxime. Când funcţionarii invocă aceeaşi sursă de date JDBC sau configuraţia fabrică de conexiuni J2C, Serverul de aplicaţii WebSphere implementează un pool de conexiune fizică corespunzător pentru fiecare funcţionar. Prin urmare acelaşi pool de conexiuni există, independent, în fiecare funcţionar. Setarea dumneavoastră Conexiuni maxime se aplică la fiecare din aceste pool-uri.

[AIX Solaris HP-UX Linux Windows] [iSeries] Toate aceste pool-uri de conexiuni corespund cu aceeaşi sursă de date sau configuraţie fabrică de conexiuni. Prin urmare toate aceste pool-uri de conexiuni pot cere potenţial conexiuni de la aceeaşi resursă back-end, în acelaşi timp. Valoarea singulară Conexiuni maxime pe care aţi setat-o pe acest panou consolă se aplică la fiecare din aceste pool-uri de conexiuni. În consecinţă, setarea unei valori mari a Conexiunilor maxime poate rezulta într-o încărcare de cereri de conexiuni care vă depăşeşte resursa de back-end.

[z/OS] Potenţial, fiecare aplicaţie care necesită sursa de date sau fabrica de conexiuni în aceşti funcţionari poate încerca să utilizeze resursa în mod simultan. Prin urmare pool-urile de conexiuni corespunzătoare necesită conexiuni de la acelaşi back-end, în acelaşi timp. Nu setaţi o valoare Conexiuni maxime care ar putea cauza ca încărcarea cererilor de conexiuni să vă depăşească baza de date sau alt sistem de informaţii întreprindere (EIS).

Tip date Întreg
Implicit 10
Interval 0 la întreg maxim

Dacă Conexiunile maxime sunt setate la 0, valoarea Timeout conexiune este ignorată.

Tip: Pentru o performanţă mai bună, setaţi valoarea pentru pool-ul de conexiuni mai mic decât valoarea pentru conexiunile pool prag maxime ale Containerului web.Configuraţi această setare prin navigarea la Servers > Tipuri servere > Servere de aplicaţii WebSphere > server > Pool-uri de fire de execuţie, şi modificaţi proprietatea WebContainer. Setări mai joase, cum ar fi 10-30 conexiuni, realizează mai bine decât setări mai înalte, cum ar fi 100.

Puteţi utiliza Vizualizatorul performanţă Tivoli pentru a găsi numărul optim de conexiuni dintr-un pool. Dacă numărul de solicitanţi concurenţi este mai mare ca 0, dar încărcarea CPU nu este aproape de 100%, consideraţi creşterea dimensiunii pool-ului de conexiuni. Dacă valoarea Procent utilizat este în mod consistent mai jos decât încărcarea de lucru normală, consideraţi scăderea numărului de conexiuni din pool.

Conexiuni minime

Specifică numărul minim de conexiuni fizice pentru a fi menţinute.

Dacă dimensiunea pool-ului de conexiuni este la sau mai jos decât dimensiunea pool-ului de conexiune minimă, firul de execuţie de Timeout neutilizat nu ignoră conexiunile fizice. Totuşi, pool-ul nu creează conexiuni exclusiv pentru a asigura că dimensiunea pool-ului de conexiuni minimă este menţinută. De asemenea, dacă setaţi o valoare pentru Timeout învechit, conexiunile cu o vârstă expirată sunt ignorate, în ciuda setării dimensiunii pool minimă.

De exemplu, dacă valoarea Conexiuni minime este setată la 3, şi o conexiune fizică este creată, firul de execuţie Timeout neutilizat nu ignoră acea conexiune. La acelaşi jeton, firul de execuţie nu creează automat două conexiuni fizice suplimentare pentru a ajunge la setarea Conexiuni minime.

Tip date Întreg
Implicit 1
Interval 0 la max int
Timp de culegere

Specifică intervalul, în secunde, între rulările firului de execuţie de întreţinere pool.

De exemplu, dacă Timpul culegere este setat la 60, firul de execuţie întreţinere pool rulează la fiecare 60 de secunde. Intervalul Timp culegere afectează precizia setărilor Timeout neutilizat şi Timeout învechit. Cu cât e mai mic intervalul, cu atât mai mare este precizia. Dacă firul de execuţie întreţinere pool este activat, setaţi valoarea Timp culegere mai mică decât valorile Timeout-ului neutilizat şi Timeout-ului învechit. Când rulează firul de execuţie întreţinere pool, acesta ignoră orice conexiune rămasă neutilizată mai mult decât valoarea timpului specificat în Timeout-ul neutilizat, până când ajunge numărul de conexiuni specificate în Conexiunile minime.Firul de execuţie întreţinere pool de asemenea ignoră orice conexiune care rămâne activă mai mult timp decât valoarea timp specificată în Timeout-ul învechit.

Intervalul Timp culegere de asemenea afectează performanţa. Intervale mai mici înseamnă că firul de execuţie întreţinere pool rulează mai des şi scade performanţa.

Pentru a dezactiva firul de execuţie întreţinere pool setaţi Timpul culegere la 0, sau setaţi ambele Timeout neutilizat şi Timeout învechit la 0. Calea recomandată pentru a dezactiva firul de execuţie întreţinere pool este să setaţi Timpul culegere la 0, în acest caz Timeout-ul neutilizat şi Timeout-ul învechit sunt ignorate. Totuşi, dacă Timeout-ul neutilizat şi Timeout-ul învechit sunt setate la 0, firul de execuţie întreţinere pool rulează, dar doar conexiunile fizice ale căror timeout corespunzător valorilor de timeout diferite de 0 sunt ignorate.

Tip date Întreg
Unităţi Secunde
Implicit 180
Interval 0 la max int
Timeout neutilizat

Specifică intervalul în secunde după care o conexiune neutilizată sau nefolosită este ignorată.

Setaţi valoarea Timeout neutilizată mai mare decât valoarea Timeout culegere pentru performanţă optimă. Conexiunile fizice neutilizate sunt ignorate doar dacă numărul curent de conexiuni depăşeşte setarea Conexiuni minime. De exemplu, dacă valoarea timeout neutilizată este setată la 120, şi firul de execuţie întreţinere pool este activat (Timpul de culegere nu este 0), orice conexiune fizică care rămâne neutilizată timp de două minute este ignorată.

Precizia şi performanţa acestui timeout sunt afectate de valoarea Timp culegere. VedeţiTimp de culegere pentru mai multe informaţii.

Tip date Întreg
Unităţi Secunde
Implicit 1800
Interval 0 la max int
Timeout învechit

Specifică intervalul în secunde înainte ca o conexiune fizică să fie ignorată.

Setarea Timeout-ului învechit la 0 suportă conexiuni fizice active care rămân în pool la infinit. Setaţi valoarea Timeout-ului învechit mai mare decât valoarea Timeout-ului culegere pentru performanţă optimă, dar Timeout-ul învechit ar trebui utilizat doar dacă este necesar.

Pentru cei mai mulţi adaptori de resurse, Timeout-ul învechit ar trebui să fie setat la 0. Timeout-ul învechit ar trebui utilizat doar când este cunoscut că o conexiune gestionată va porni veche. De exemplu, o conexiune gestionată IMS va înceta să funcţioneze după ce istoricul nativ atinge o limită pentru această conexiune gestionată. Dacă istoricul rămâne fără spaţiu în 30 de minute, ar trebui să setaţi Timeout-ul învechit la 25 de minute. Aceasta permite pentru curăţarea conexiunii gestionate şi resurselor de back-end să fie eliberate.

Un alt exemplu este dacă valoarea Timeout-ului învechit este setată la 1200, şi valoarea Timpului culegere nu este 0, orice conexiune fizică care rămâne în existenţă timp de 1200 de secunde (20 de minute) este ignorată de la pool. Singura excepţie este dacă conexiunea este implicată într-o tranzacţie când timeout-ul învechit este ajuns, serverul de aplicaţii nu va ignora conexiunea până când după ce tranzacţia este finalizată şi conexiunea este închisă.

Precizia şi performanţa acestui timeout sunt afectate de valoarea Timpului culegere. Vedeţi Timp de culegere pentru mai multe informaţii.

Tip date Întreg
Unităţi Secunde
Implicit 0
Interval 0 la max int
Politică de epurare

Specifică cum să epuraţi conexiunile când o conexiune veche sau o eroare de conexiune fatală este detectată.

Valorile valide sunt EntirePool şi FailingConnectionOnly.

Tip date Şir
Implicite
  • EntirePool pentru fabricile de conexiuni J2C şi fabricile de conexiuni înrudite JMS
  • EntirePool pentru sursele de date WebSphere versiune 4.0
  • EntirePool pentru sursele de date de versiune curentă pe care le creaţi prin consola administrativă
  • EntirePool pentru sursele de date de versiune curentă pe care le scriptaţi prin comenzile wsadmin AdminConfig, invocând şabloane JDBC care sunt construite în Serverul de aplicaţii WebSphere (Pentru mai multe informaţii despre comanda createUsingTemplate, vedeţi articolul centrului de informaţii "Comenzi pentru obiectul AdminConfig.")
  • FailingConnectionOnly pentru sursele de date pe care le scriptaţi în wsadmin fără a invoca şabloane JDBC
:
Interval
EntirePool
Toate conexiunile din pool sunt marcate ca vechi. Orice conexiune care nu este utilizată este închisă imediat. O conexiune care este utilizată este închisă şi lansează în utilizare o Excepţie conexiune veche în timpul următoarei operaţii pe acea conexiune. getConnection() următoare cer de la rezultatul aplicaţiei în conexiunile noi la deschiderea bazei de date. La utilizarea politicii de epurare, există posibilitatea mică ca unele conexiuni din pool să fie închise în mod nenecesar când nu sunt vechi. Totuşi, aceasta este o apariţie rară. În cele mai multe cazuri, o politică de epurare a EntirePool este cea mai bună alegere.
FailingConnectionOnly
Doar conexiunea care a cauzat excepţia conexiune veche este închisă. Deşi această setare elimină posibilitatea ca conexiuni valide să fie închise nenecesar, face ca recuperarea de la o perspectivă de aplicaţie să fie mai complicată. Deoarece doar conexiunea de eşuare curentă este închisă, există o bună posibilitate ca următoarea cerere getConnection() de la aplicaţie poate returna o conexiune de la pool-ul care este de asemenea vechi, rezultând în excepţii conexiuni mai vechi.

Funcţia pretestare conexiune încearcă să separe o aplicaţie de la conexiunile pool care nu sunt valide. Când o resursă back-end, cum ar fi o bază de date, coboară, conexiunile pool care nu sunt valide ar putea exista în pool-ul liber. Aceasta este îndeosebi adevărată când politica de epurare este failingConnectionOnly; în acest caz, conexiunea de eşuare este înlăturată de la pool. În funcţie de eşuare, conexiunile care rămân în pool ar putea să nu fie valide.




Legăturile marcate (online) necesită acces la internet.

Related concepts
Related tasks
Related reference


Nume fişier: udat_conpoolset.html