L'envie est grande en effet de préparer la requête paramétrée une bonne fois pour toute en amont et de ne garder dans la méthode que le remplissage des paramètres et l'exécution. cela paraît plus optimal.
Mais, rien ne garanti que l'implémentation, fournie par le driver jdbc, est thread safe et donc que le PreparedStatement peut être utilisé en environnement multi-threadé.
si tu es sur que ton exécution est mono-threadé, tu peux éventuellement faire cette optimisation. mais:
1/ tu prends un risque sur la maintenabilité de ton application: passage en multi-threadé impossible sans refacto, ou, plus surement, bug lors du passage en multi-threadé en ayant oublié cette limitation.
2/ ton optimisation ne sert surement à rien pour la plupart des implémentations (oracle en tête).
Bref, à peser le pour et le contre.
# thread safe
Posté par steph1978 . En réponse au message Bon usage de PreparedStatement. Évalué à 2.
Mais, rien ne garanti que l'implémentation, fournie par le driver jdbc, est thread safe et donc que le PreparedStatement peut être utilisé en environnement multi-threadé.
si tu es sur que ton exécution est mono-threadé, tu peux éventuellement faire cette optimisation. mais:
1/ tu prends un risque sur la maintenabilité de ton application: passage en multi-threadé impossible sans refacto, ou, plus surement, bug lors du passage en multi-threadé en ayant oublié cette limitation.
2/ ton optimisation ne sert surement à rien pour la plupart des implémentations (oracle en tête).
Bref, à peser le pour et le contre.