Table des Matières
Publicité
Exemple de prise en charge des transactions XA
1. Envisagez un environnement nécessitant au moins 4000 connexions
simultanées. Un serveur Web qui utilise les applications CGI ou un système
Office avec de nombreux utilisateurs du bureau peuvent tout deux dépasser
cette exigence. Dans ce cas, pour que le système soit efficace, DB2 Connect
devra fonctionner comme une passerelle indépendante, c'est-à-dire que la base
de données et le système DB2 Connect doivent se trouver sur la même
machine.
Il se peut que le serveur DB2 Connect ne soit pas en mesure de gérer
4000 connexions ouvertes simultanément dans la machine de base de données.
Dans la plupart des cas, le nombre de transactions établies à n'importe quel
moment sera considérablement inférieur au nombre de connexions
concurrentes. L'administrateur système peut alors optimiser l'efficacité du
système en définissant les paramètres de configuration de la base de données
comme suit :
MAX_CONNECTIONS = 4000
MAX_COORDAGENTS = 1000
NUM_POOLAGENTS = 1000
Le concentrateur conservera ouvertes les 4000 connexions simultanées, même
si la passerelle ne gère que 1000 transactions à la fois.
2. Dans l'exemple susmentionné, les agents exécutants forment et rompent
constamment des associations avec les agents logiques. Ces agents qui ne sont
pas en veille peuvent gérer une connexion à la base de données mais ne
prennent part à aucune transaction particulière ; ils sont par conséquent
disponibles pour n'importe quel agent logique (application) qui demande une
connexion.
Le cas des transactions est quelque peu différent. Dans cet exemple, supposons
qu'un moniteur TP est utilisé avec une passerelle DB2 Connect et une base de
données System z ou IBM Power Systems. Lorsqu'une application demande
une connexion, le concentrateur active un agent inactif pour prendre en charge
la requête ou crée un nouvel agent exécutant. Supposons que l'application
demande une transaction XA. Un XID (ID transaction) est créé pour cette
transaction et l'agent exécutant est associé à cet XID.
Lorsque la demande de l'application a été traitée, elle émet un xa_end() et se
désassocie de l'agent exécutant. L'agent exécutant reste associé au XID de la
transaction. Il ne peut désormais prendre en charge que des demandes de
transaction possédant cet XID associé.
Une autre application peut alors demander une transaction non XA. Même si
aucun autre agent exécutant n'est disponible, l'agent associé au XID ne sera pas
disponible pour cette seconde application. Il est considéré comme actif. Un
nouvel agent exécutant sera créé pour cette seconde application. Lorsque cette
application termine sa transaction, son agent d'exécution est libéré dans le
regroupement disponible.
Entre-temps, d'autres applications requérant la transaction associée au premier
XID de l'agent peuvent s'associer et se désassocier de l'agent qui exécute sa
transaction XA dédiée pour elles. Toute application requérant cette transaction
particulière sera envoyée à cet agent exécutant s'il est libre.
L'agent exécutant ne sera pas libéré dans un regroupement général tant que
l'application n'émettra pas un appel de fin de transaction (autre que xa_end()).
Par exemple, une application peut mettre un terme à la transaction à l'aide de
xa_commit(), moment à partir duquel l'agent exécutant rompt son association
Chapitre 4. Réglage et DB2 Connect
95
Publicité
Table des Matières
