Discussion :

[mabool]

Bonjour,

J'ai developpé une application J2EE (Servlets et JSP), sous Tomcat et ayant accès à une base de données Access.

J'ai mis mon application en intranet, de cette façon, toute personne peut l'utiliser. Comment pourrai-je assurer que l'application continuera à être utilisée, même avec un très grand nombre d'utilisateurs, sachant que l'accès à la base de données doit être établi à chaque requête-réponse ?

Vos suggestions seront les bienvenues.

[tchize_]

je suis pas le seul sur le forum je pense qui te le dira:


J2EE, access, et grand nombre d'utilisateurs, ca n'a pas à être dans la même phrase. Access et une base de données de type prototypage, a ne pas utiliser en production. Ce n'est pas réputé pour etre performant. Ensuite, par rapport à java, pour utiliser access t'as du utiliser un bridge ODBC-JDBC, qui est clairement indiqué comme non recommandé par sun (mais on a pas le choix avec access, y a que ca)

Donc recommandation
1) remplace access par une vraie base de donnée (mysql, postgres, oracle, sqlserver, db2 ibm, hsql, derby....) ce sont pas les choix qui manquent
2) pour la connection DB, ne fait pas une connection à chaque requete, utilise du connection pooling. Etablir une connection, sur un oracle surchargé, ca peut mettre jusqu'à 2 seconde, alors que les requetes s'executent dessus en quelques millisecondes.
3) calibre (par essais/erreur) la taille de ton HTTP thread de tomcat. Plus de thread = plus de requetes simultanées mais aussi = des requetes plus lentes
4) en fonction du calibrage de tes thread HTTP, calibre ton conneciton pool jdbc.

[mabool]

Merci infiniment pour les recommandations; j'en tiendrai compte.

Est-ce que le problème des accès multiples se posera encore, avec l'utilisation d'une base de données SQL Server ?

[tchize_]

le problème n'est pas dans les accès multiples (les transactions servent justement à isoler ça) mais dans les performance de access qui n'est pas prévu pour autre chose que du prototypage ou des application minis rikiki. Bref il a mauvaise réputation pour pleins de raisons. Avant d'investire dans un serveur payant (sql server) regarde si t'en a vraiment besoin par rapport aux serveurs gratuits. Ce sont souvent des très gros serveur qui ont aussi des frais de maintenance.

Note, si tu lit a fond la doc JDBC/ODBC tu verra qu'elle ne permet pas des connection simultanée, et ça c'est pas lié à access mais à odbc.

[mabool]

Le problème du serveur SQL Server ne se poserait pas, dans mon cas.

Note, si tu lit a fond la doc JDBC/ODBC tu verra qu'elle ne permet pas des connection simultanée, et ça c'est pas lié à access mais à odbc.

J'avoue être vraiment confuse concernant ce dernier point.

[tchize_]

C'est indiquée ici:

http://java.sun.com/products/jdbc/faq.html#14

en cas de multithreading (ce qui est le cas des application J2EE), tu perd tous les avantage du multithreading à cause des blocs synchronizé -> tout fonctionne comme si une seule connection était active à la fois.

[mabool]

J'ai saisi le point.

Autre question, y aurait-il un moyen d'y remédier ? ou bien une alternative ?

[tchize_]

jete les ai données, les alternatives, utiliser autre chose que access.

[mabool]

(à moitié résolu)

Merci bien; et bonne journée.