db2_pconnect ou db2_connect ?

Apache sera actif (quelle que soit l’application PHP qui utilise la connexion persistante). A l’inverse, db2_connect() ouvrira une connexion chaque fois qu’une application PHP voudra utiliser la base de données et fermera la connexion à la sortie. Par conséquent, db2_connect sollicite énormément les ressources i5 avec des ouvertures/fermetures de base de données à une vitesse de demande de requête subseconde de la part des clients du navigateur (aïe !), tandis que les demandes ultérieures adressées à db2_pconnect contournent tout le travail de connexion db2.

Vous ne pouvez pas mélanger db2_connect et db2_ pconnect sous la même connexion de profil utilisateur, car le db2_pconnect risque de consommer toutes les connexions et de les garder en otages pendant la durée de vie du site Apache. La fonction persistante de ibm_db2 est indispensable pour la performance, mais elle a son prix : savoir planifier votre stratégie de site ibm_db2 pour éviter que la totalité du site ne devienne insensible aux requêtes db2.

Vous vous en doutez peut-être, db2_pconnect() est une connexion stateful ; donc elle viole les règles de programmation stateless Apache. DB2_I5_NAMING_ON s’attend à ce que toutes les instructions SQL aient la syntaxe library/file (native/system naming) et DB2_I5_NAMING_OFF s’attend à ce que toutes les instructions SQL aient library.name (SQL naming). En raison des règles de connexions CLI, nous ne pouvons pas faire alterner les deux modes pendant qu’une connexion est active (donc, db2_pconnect est toujours actif).

L’application Acme PHP est configurée pour s’approprier la connexion NOBODY du profil par défaut (config.php), avec la conséquence suivante : bon nombre de nos autres scripts de test (ou autre code db2 de production) qui essaieront de mélanger db2_pconnect/connect ("", "", "") et db2_connect("","",""), array("i5_naming"=>DB2_I5_ NAMING_ON)) échoueront. (Ou bien, si votre autre application PHP tient déjà en otage la connexion persistante, l’application Acme échouera.) La réponse simple et courte à ce problème consiste à choisir simplement des profils différents pour chaque classe générale de connexion persistante ibm_db2 stateful : un pour DB2_I5_NAMING_ON et un autre pour DB2_I5_ NAMING_OFF. Je recommande d’avoir au moins deux profils utilisateurs *USER qui ne peuvent pas se connecter (sign on) au System i (comme NOBODY et NOBODYP) pour exécuter les deux styles de db2_pconnect pour les applications PHP, puis de penser à se connecter avec le profil correspondant.

Remarque: Toute violation stateless Apache est un véritable pacte avec le diable : il faut en payer le prix. D’ailleurs, du point de vue d’Apache, changer le code RPG est une meilleure solution. Donc, si vous devez mélanger le nommage SQL et system/native et des listes de bibliothèques, choisissez avec beaucoup de soin la stratégie de connexion persistante ibm_db2 de votre site (db2_pconnect est un outil puissant mais dangereux entre les mains de votre spécialiste Web).