Coucou!
Merci pour ta réponse!
Très intéressant tout ça!
Je trouve ça dommage qu'il soit si difficile, voir impossible, de trouver des infos, par exemple via une simple recherche google, concernant le fonctionnement interne de PHP-Apache sans avoir à jouer les spéléologues dans la doc officielle...
Donc, si j'ai bien compris, Apache garde un ou plusieurs processus actifs, dédiés à mon site et, quand des clients se connectent :
- Apache dirige la requête vers le processus le moins chargé;
- Ce processus crée un processus enfant à moins d'en disposer d'un qui soit libre et pas encore détruit;
J'aimerais être sûr d'une chose : une connexion ne peut gérer qu'une transaction à la fois, n'est-ce pas?
Vu que mon site dispose d'un hébergement 1&1 minimal pour sites scriptés, à pas trop chère, j'imagine que peu de connexions concurrentes peuvent être ouvertes... Et donc, il faut que je sois sûr qu'une connexion persistante l'est avec mon site tout entier, et pas seulement avec un sous-processus de traitement... L'idéal serait que chaque new PDO obtienne bien l'instance du driver, même s'il est actuellement utilisé, puis qu'ensuite, Apache se débrouille..!
Ici,
http://www.php.net/manual/fr/features.p ... ctions.php, les 2 paragraphes avant l'encadré d'avertissement me paraissent flous!
- Une connexion par processus enfant?
- Si le nombre de connexions est atteint, les processus enfants suivant restent sur le carreau?
- Ca veut dire qu'il faudrait que le nombre maximum de processus enfant soit inférieur ou égal au nombre maximum de connexions?
- Et, par rapport aux transactions, une transaction ouverte par une requête d'un client peut être fermée par une autre requête. Une requête de ce même client ou par n'importe quelle requête de n'importe quel client?
Quant au blog de Misko, si j'ai bien compris, il incite à hiérarchiser des Factory dans le but d'éviter les membres globaux..?
Seulement, en PHP, rien ne nous empêche de découper notre application en 150 includes! Et, à ce moment-là, il est impossible de savoir quand le PDO est instancié! Alors, une méthode du style Application::getPDO() peut paraitre intéressante...
D'un autre côté, si la classe Application se charge de toutes les instanciations, ce serait à elle de passer la connexion à qui en a besoin... J'ai pigé?
Bon, du coup, la classe Application ça l'empêche pas d'être un Singleton, si?
Parce qu'on pourrait très bien avoir besoin d'une instance d'Application dans un fichier qui n'est pas sensé savoir qu'elle a déjà été instanciée!
Ou s'il le faut vraiment, dans un soucis de clarté, est-ce que ceci pourrait être une bonne idée?
class Application {
private static $existe = false;
public function __construct() {
if (self::$instance instanceof self) {
throw new Exception('Classe Application déjà instanciée précédemment');
}
self::$exist = true;
}
}
De cette façon, on est obligé d'instancier l'Application pour l'utiliser, et on s'assure qu'il n'existera pas 2 instances d'Application tout en prenant soin d'informer le programmeur qu'une erreur s'est glissée dans son modèle de conception et qu'il a malencontreusement chié dans la soupe en essayant d'instancier à nouveau la classe Application!
Je me demande aussi pourquoi Misko sépare l'instanciation de la classe Application et son initialisation? On pourrait l'initialiser dans le constructeur, non?
Encore merci pour cette grande baffe dans ma face! J'ai tendances à abuser des Singleton et des membres statiques et, c'est vrai que parfois, c'est terriblement chiant à débugguer! Ca va beaucoup m'aider à recentrer ma façon de coder vers des pratiques moins "evil"!
