OCI: si possible, utiliser l'OCILIB

Dernièrement, j'ai travaillé sur une interface C écrite en OCI natif. Sans rentrer dans les détails, elle était d'une piètre qualité, en particulier les requêtes n'étaient pas bindées ...

Si vous avez le choix, je vous conseille vivement d'utiliser l'OCILIB plutôt que d'attaquer directement la couche native. Dans le cas contraire, inspirez-vous du code source de l'OCILIB disponible à cette adresse. Des exemples sont également fournis dans la doc officielle.

Mais de grâce, ne réinventez pas la roue !

Si vous avez besoin d'un bulk collect en OCI, voici un exemple.

OCILIB

Après quelques tests, je vous incite à découvrir cette librairie. Elle dispose de nombreuses fonctionnalités, la mémoire est très bien gérée ( pas de fuite ) et  ses performances sont comparables à celles du PRO*C. 

En plus des exemples de code fournis sur le site officiel, voici quelques exemples supplémentaires afin de vous faire une première idée sur le sujet.

Pour information, lors du test d'un failover de type serveur sur un RAC 10g, le programme utilisant un pool de connexion ( test_pool.c ) a généré un coredump ( OCI-21500 ) lors de l'arrêt d'une instance ou d'un service. Il serait intéressant d'effectuer le même test sur une architecture 11g ( client + RAC ) pour voir si l'erreur perdure.

Pour un failover de type client, on n'obtient plus de coredump mais une erreur ORA-03113 ( end-of-file on communication channel ). On aurait préféré une erreur dans l'intervalle 25400-25425. Heureusement, le programme reprend après cette erreur ...
 

OCILIB

Actuellement, je participe à un projet de réécriture d'une librairie C d'accès aux bases Oracle ( code peu maintenable, allocation mémoire trop importante, ... ). Pour ce faire, nous avons décidé d'utiliser la librairie ocilib, une encapsulation de la couche OCI. Dans notre cas de figure, on travaille sur une machine Solaris et on utilise un client Oracle 10g.

Notre cahier des charges est le suivant:
- Pool de connexion client;
- Appel à des procédures stockées utilisant des bind variables;
- Exécution de requêtes utilisant des bind variables;
- Utilisation du package dbms_output.

A mon avis, cette librairie open source offre les deux avantages suivants:
- Code plus concis et plus lisible qu'en PRO*C, d'où une meilleure maintenabilité;
- API moins complexe à mettre en oeuvre que le PRO*C; on se rapproche d'une API de type JDBC.

Par ailleurs, on a demandé à Vincent Rogier de nous accompagner pendant les développements, ce qu'il a accepté.

Pour le moment, les développements se passent bien.

Reste quelques points à vérifier ultérieurement:
- Gestion de la mémoire ( fuite );
- Performance attendue de l'ordre de la dizaine de ms.