>>> Et toute base qui se respecte écrit les modifications sur le disque de manière synchrone
La j'ai un gros doute, en plus c'est quoi une base "qui se respecte" ?
Pour moi un SGBD qui se respecte est celui qui fait ce qu'on lui demande, qui correspond au besoin, et qui permet de rapidement faire une restauration en cas de crash (voire eviter le crash).
Donc j'insiste mais a part ecrire une application susceptible de gérer les états d'une centrale nucleaire, pour un site marchant, meme consequant ton exemple est mauvais.
Pourquoi ?
Parce que tant que le client n'a pas validé sa demande, il est inutile (J2EE ou pas d'ailleur) de stoquer quoi que ce soit en base. tout peut se faire via cookie ou simple parametre post sur une page HTML. Ce qui va dégager des ressource sur le serveur, donc necessister un serveur moins puissant, donc moins cher. De plus que l'on ait 1 ou 100000000000000 clients ce n'est pas ca qui pénalisera le serveur.
Ensuite, la remarque :
Sans compter le transfert des données par le réseau vers la BD
n'a pas lieu d'être, même un particulier peut se payer du 100Mb a la maison, imagine ce que peu se payer une société qui a un site marchand encaissant des miliers de connexions par heure (faut au moins ca pour rentabilier le cout d'exploitation d'un J2EE).
Et pour finir avec le coup des "log de transaction", a moins que tu ne parle d'un Oracle sur un raw device (ou sybase) , ca revient au meme.
Ton log est un fichier, l'ecriture est géré par le noyau (je prend le cas d'un linux), auquel cas la notion de cache en ecriture existe aussi et ont retomber sur mon exemple précérend!
[^] # Re: Marrant, ça...
Posté par elamapi . En réponse au journal Apache/PHP et J2EE. Évalué à 1.
La j'ai un gros doute, en plus c'est quoi une base "qui se respecte" ?
Pour moi un SGBD qui se respecte est celui qui fait ce qu'on lui demande, qui correspond au besoin, et qui permet de rapidement faire une restauration en cas de crash (voire eviter le crash).
Donc j'insiste mais a part ecrire une application susceptible de gérer les états d'une centrale nucleaire, pour un site marchant, meme consequant ton exemple est mauvais.
Pourquoi ?
Parce que tant que le client n'a pas validé sa demande, il est inutile (J2EE ou pas d'ailleur) de stoquer quoi que ce soit en base. tout peut se faire via cookie ou simple parametre post sur une page HTML. Ce qui va dégager des ressource sur le serveur, donc necessister un serveur moins puissant, donc moins cher. De plus que l'on ait 1 ou 100000000000000 clients ce n'est pas ca qui pénalisera le serveur.
Ensuite, la remarque :
Sans compter le transfert des données par le réseau vers la BD
n'a pas lieu d'être, même un particulier peut se payer du 100Mb a la maison, imagine ce que peu se payer une société qui a un site marchand encaissant des miliers de connexions par heure (faut au moins ca pour rentabilier le cout d'exploitation d'un J2EE).
Et pour finir avec le coup des "log de transaction", a moins que tu ne parle d'un Oracle sur un raw device (ou sybase) , ca revient au meme.
Ton log est un fichier, l'ecriture est géré par le noyau (je prend le cas d'un linux), auquel cas la notion de cache en ecriture existe aussi et ont retomber sur mon exemple précérend!