Profil de aplicaţie |
|
![]() |
Rulare | Note tehnice | Javadoc | Construire cu Ant |
Localizarea tabelelor de bază de date |
Localizarea codului sursă |
Examinarea notelor despre codare |
Folosirea serviciului de profil aplicaţie |
Numele bazei de date pentru acest Exemplu este Account. Tabela poate fi găsită în baza de date AppProfileSampleDB. Pentru a deschide baza de date şi vizualiza tabela, consultaţi ghidul utilizatorului bazei de date Derby.
Codul sursă poate fi găsit în directorul profile_root/samples/src/AppProfile
z/OS: Codul sursă pentru Exemple nu este furnizat pe platforma z/OS deoarece aplicaţiile Exemplu nu sunt construite pe platforma z/OS.
Privire generală |
Servletul AccountManagementServlet |
Bean-ul sesiune fără menţinere de stare AccountManager |
Bean-ul entitate CMP Account 2.1 |
Exemplul Application Profile Account Management foloseşte tipuri de componentă J2EE pentru a demonstra cum să se folosească serviciul de profilare aplicaţie:
Aplicaţia Account Management este controlată de servletul AccountManagementServlet. Servletul AccountManagementServlet interacţionează cu bean-ul sesiune fără menţinere de stare AccountManager care invocă bean-ul entitate CMP, Account. Persistenţa bean-ului entitate este influenţată de profilurile de aplicaţie care sunt definite folosind uneltele urnizate cu Application Server.
Servletul AccountManagementServlet furnizează utilizatorilor trei opţiuni:
Realizaţi acţiunea 1 pentru a crea conturi înainte de a realiza acţiunile 2 sau 3.
Fiecare acţiune invocă o metodă business corespunzătoare pe un bean sesiune AccountManager.
Bean-ul sesiune fără menţinere de stare AccountManager
Bean-ul sesiune AccountManager ia comenzile de la servletul AccountManagementServlet şi face invocări la bean-ul entitate CMP, Account. Bean-ul sesiune AccountManager a fost configurat de Assembly Toolkit cu politicile de taskuri administrate de container. Aceste politici gestionează taskul asociat cu o cerere particular la bean-ul sesiune, prin aceasta suportând metode diferite ale bean-ului sesiune care să controleze rezoluţia diferitelor profiluri de aplicaţie şi politicile de intenţie acces pe bean-ul entitate Account.
Account este un bean entitate CMP 2.1. El conţine şi gestionează datele contului, cum ar fi ID-ul contului, balanţa, tipul de cont şi ARP-ul Bean-ul entitate Account este configurat cu profiluri de aplicaţie şi politici de intenţie acces. Taskurile configurate pe fiecare profil controlează ce politică de intenţie acces se aplică pentru orice cerere dată. Profilurile de aplicaţie sunt create folosind Assembly Toolkit.
Serviciul de profilare aplicaţii furnizează un mecanism pentru dezvoltatori pentru a
configura aplicaţiile lor J2EE cu informaţii de care au nevoie containerul şi
managerul de persistenţă pentru a obţine cele mai bune optimizări de performanţă posibile fără a compromite integritatea datelor.
Assembly Toolkit este unealta principală prin care aplicaţiile sunt configurate cu
informaţii de profil de aplicaţie; datele de configuraţie sunt memorate în
descriptorii de implementare ai aplicaţiei. Această secţiune vă poartă prin
configurarea exemplului AccountManagement pentru a iniţia dezvoltatorii în folosirea acestei noi tehnologii.
Definirea cerinţelor de intenţie acces
Primul pas în folosirea serviciului de profilare aplicaţie este să înţelegeţi problemele de persistenţă care trebuie rezolvate pentru o aplicaţie particulară. Acest task necesită o înţelegere foarte clară a designului aplicaţiei şi a mediului în care aplicaţia rulează. Profilurile de aplicaţie vă ajută să reliefaţi gâtuirile identificate precis cauzate de o regie de persitsenţă care nu este necesară.
Exemplul AccountManagement are un singur multifinder pe bean-ul entitate Account:
getLargeAccounts (double balance)
Implicit, această metodă este invocată întotdeauna cu politica de intenţie acces wsPessimisticUpdate-WeakestLockAtLoad. Privind mai de aproape cum lucrează de fapt această metodă, se vede clar că este departe de ideal. Următoarele metode de pe bean-ul sesiune invocă metoda de entitate getLargeAccount:
getLargeAccounts (double balance)
increaseLargeAccountsAPR(double balance, double change)
Metoda getLargeAccounts este o operaţie doar-citire; toate conturile mai mari
decât o anumită balanţă sunt returnate doar în scopul afişării.
Metoda increaseLargeAccountsAPR este o operaţie doar-actualizare; tuturor conturilor mai mari
decât o anumită balanţă li se actualizează APR-ul cu o anumită sumă.
Dar, din cauză că metoda getLargeAccounts este întotdeauna invocată cu actualizare
pesimistă, operaţia de citire trebuie să aştepte pentru ca operaţia de actualizare
să se termine, înainte de a putea obţine rezultatele. Configurarea metodei cu o politică
wsPessimisticRead în mod cert rezolvă câteva probleme de performanţă, dar cu costuri în integritatea datelor.
Soluţia cea mai bună este să configuraţi bean-ul entitate să folosească o politică
de citire când este invocat cu intenţii de citire şi să folosească o politică de
actualizare când este invocat cu intenţii de actualizare.
Serviciul de profilare aplicaţie face posibilă această configuraţie.
Crearea unei politici de intenţii acces personalizate
Acum când ştiţi cum vreţi să se comporte bean-ul entitate în contextul mai
multor cereri, este timpul să vedeţi configuraţia politicilor de intenţii acces implicite.
Această operaţie necesită un răspuns la următoarea întrebare: Cum vor fi tratate de
către container şi de către managerul de persistenţă cererile pentru care sistemul
nu le cunoaşte intenţia?
Această problemă este cel mai bine pusă în evidenţă de scenariul celui mai rău caz: presupunerea că este vorba de actualizări.
Această presupunere este făcută pentru acest exemplu, dar puteţi încerca să
configuraţi incrementul de colectare la o valoare mai mare decât valoarea implicită de
unu, prin aceasta reducând numărul de cereri la distanţă între bean-ul sesiune şi bean-ul entitate.
Aplicarea unei politici ca politică de intenţii acces implicită
WebSphere Application Server livrează şapte politici de intenţii acces implicite
care pot fi aplicate metodelor unui bean entitate CMP. Politica creată în pasul
anterior al acestui exemplu adaugă o nouă politică personalizată care poate fi acum
aplicată unui bean entitate CMP EJB 2.1. Pentru a seta politica personalizată ca şi
politică de intenţii acces implicită pentru bean-ul entitate CMP EJB 2.1, realizaţi următoarele acţiuni:
Crearea unui profil de aplicaţie
Aşa cum s-a menţionat anterior, politica implicită aplicată în secţiunea anterioară nu este corespunzătoare pentru toate cererile. Pentru ca managerul de persistenţă şi containerul să distingă intenţia unei cereri particulare, trebuie create profilurile de aplicaţie. Deoarece un profil de aplicaţie conţine o listă de intenţii de acces şi taskuri, crearea unui profil de aplicaţie implică şi crearea politicilor de intenţii de acces şi a taskurilor. Pentru exemplu nostru simplu, un singur profil este suficient.
Aţi asociat acum o intenţie de acces actualizare pentru bean-ul entitate Account şi o politică de intenţii acces citire folosind un profil. Cum poate să determine containerul şi managerul de persistenţă la momentul rulării ce politică să ia în considerare? Până acum, doar intenţia de actualizare implicită este aplicată. Aveţi nevoie de un mod de a distinge identitatea cererilor din bean-ul nostru sesiune. Puteţi da instrucţiuni runtime-ului prin intermediul identităţii cererii. Aşa cum s-a discutat anterior, operaţia de actualizare pe bean-ul entitate este întotdeauna controlată de metoda increaseLargeAccountsAPR de pe bean-ul sesiune AccountManager. Deoarece intenţia de acces implicită a bean-ul entitate Account este intenţia de acces actualizare, nu este nevoie să configuraţi această metodă increaseLargeAccountsAPR. Ea este rulată întotdeauna sub intzenţia de acces actualizare implicită.
În continuare, doriţi să configuraţi un task pe metoda getLargeAccounts pe bean-ul sesiune AccountManager. Folosiţi acest task pentru a identifica cererea la profilul de aplicaţie. Reţineţi că cererea trebuie să conţină un context UOW (unit-of-work), cum ar fi o tranzacţie sau o sesiune actvitate, deoarece taskul este parte a unei unităţi de lucru (UOW). Următoarea secţiune va explica cum să faceţi partea de task a unui UOW. Fiecare cerere făcută la metoda getLargeAccounts este asociată cu taskul creat în această secţiune. Aceste task este apoi propagat la toate cererile făcute în cadrul metodei getLargeAccounts şi pot fi folosite pentru a identifica intenţia acestei metode particulare.
Configurarea atributelor tranzacţiei
Principiul de design al acestei aplicaţii este folosirea bean-ului sesiune AccountManger ca un controler care determină ce politică de intenţie acces să se aplice bean-ului entitate Account. De aceea, AccountManager va gestiona şi unitatea de lucru (UOW) asociată cu cererea. Deşi tipul UOW poate fi o tranzacţie sau o sesiune activitate, această aplicaţie se ocupă doar de tipul tranzacţie de UOW. În cazul bean-urilor tranzacţie gestionate de container, cum ar fi bean-ul AccountManager şi Account, tranzacţia este determinată de configuraţia atributului tranzacţie definită în descriptorul de implementare.
Aţi configurat un task pe metoda getLargeAccounts a bean-ului AccountManager. Pentru a face taskul parte a unei unităţi de lucru (UOW), care este o tranzacţie în acest caz, trebuie să configuraţi atributul transaction al metodei getLargeAccounts ca RequiresNew, astfel încât o nouă tranzacţie va începe la punctul de invocare a metodei getLargeAccounts şi taskul configurat pe acea metodă va deveni parte a acestei noi tranzacţii. Reţineţi că dacă metoda getLargeAccounts nu este configurat cu atributul transaction RequiresNew, se va renunţa la taskul configurat pe ea. Vă rugăm consultaţi documentaţia pentru Profil aplicaţie pentru informaţii suplimentare.
Mai departe aveţi de configurat atributul tranzacţie al metodei findLargeAccounts a bean-ului Account ca Mandatory, astfel încât metoda findLargeAccounts se va executa în domeniul (scope) tranzacţiei care vine cu cererea. Dacă cererea vine de la metoda getLargeAccounts a bean-ului AccountManager, tranzacţia conţine taskul configurat pe metoda getLargeAccounts. Acest task va fi folosit în serviciul Application Profile pentru a determina ce politică de intenţii acces se aplică bean-ului Account.
Pentru a simplifica configuraţia, puteţi configura fiecare metodă a bean-ului AccountManager cu atributul de tranzacţie RequiresNew şi fiecare metodă a bean-ului Account cu atributul tranzacţie Mandatory.
Observarea politicilor WebSphere de intenţie acces predefinite
WebSphere Application Server se livrează cu şapte politici de intenţie acces predefinite:
Access type = pessimistic update
Exclusive = false
No collision = false
Weakest lock at load = true
Collection scope = transaction
Collection increment = 1
Resource manager prefetch increment = 1
Read ahead hint = null
Access type = pessimistic update
Exclusive = false
No collision = false
Weakest lock at load = false
Collection scope = transaction
Collection increment = 1
Resource manager prefetch increment = 1
Read ahead hint = null
Access-type = optimistic update
Collection scope = transaction
Collection increment = 25
Resource manager prefetch increment = 25
Read ahead hint = null
Access-type = optimistic read | pessimistic read
Collection scope = transaction
Collection increment = 25
Resource manager prefetch increment = 25
Read ahead hint = null
Access-type = pessimistic update
Collection scope = transaction
Collection increment = 25
Resource manager prefetch increment = 25
Read ahead hint = null
Access-type = pessimistic update
Collection scope = transaction
Collection increment = 1
Resource manager prefetch increment = 1
Read ahead hint = null