Callback aux clients

Bonjour à tous,

L'architecture de mon projet est très simple, un client lourd se connecte à une base de données oracle 9i.

Chaque utilisateur se connecte avec ce client lourd codé en C++.
Il peut donc y avoir plusieurs utilisateurs connectés en même temps sur la base de données oracle, chacun utilisant le client lourd sur sa machine.(Un cas très classique en somme).

Je voudrais que dès qu'un utilisateur Insert/Update/Delete dans une table, Oracle indique à tous les utilisateurs connectés que cette table a été mise à jour.

L'idée est d'effectuer une gestion de cache au niveau des clients lourds et que la base de données signifie à chaque client de se mettre à jour.

Questions:
- Est ce possible?
- Si oui, comment?

Pour info, j'utilise la librairie OTL pour me connecter à la base de données.
http://otl.sourceforge.net/

il y a les triggers pour ca

http://download.oracle.com/docs/cd/B...htm#ABC1032282

mais ...
l'interet ici me semble ....

imagine que t'as 23000 tables type SAP et 1000 utilisateurs .... ?

Citation:

---

Envoyé par escafr

... Je voudrais que dès qu'un utilisateur Insert/Update/Delete dans une table, Oracle indique à tous les utilisateurs connectés que cette table a été mise à jour.

L'idée est d'effectuer une gestion de cache au niveau des clients lourds et que la base de données signifie à chaque client de se mettre à jour.

---

Bonjour

Il y a de fortes chances que ce soit un faux besoin et une très mauvaise idée.
Pouvez-vous préciser en quoi les mécanismes normaux d'Oracle sont inadaptés à votre situation, et nécessiteraient une gestion de cache au niveau client ?

Je partage l'avis de Pomalaix si c'est généralisé à la toute les tables de la DB.

Par contre limité à certains ensembles de données, ce qui peut être intéressant, ce sont les "Continuous Query Notification" ou encore appelé "Database Change Notification" en OCI...

Lien sur la doc Oracle sur cette notion

Mais je doute que OTL les gère....

Merci pour vos réponses.

Évidement que ce ne sera pas généralisé à toutes mes tables, mais seulement à certaines tables qui sont peut mise à jour (genre max 10 fois/mois).

Ce que Vincent Rogier me propose semble me convenir, par contre l'exemple est absolument peu clair, je vais me pencher dessus. Et ça oblige à utiliser OCI directement si je comprend bien.... :(

Par contre, je vois pas comment les triggers peuvent répondre à mon besoin?:?

EDIT: commentaire sur OCI

EDIT 2: Solution par OTL: http://otl.sourceforge.net/otl4_ex585.htm :yaisse2:

zut... Moi qui pensait que OTL ne gérait pas les DNC....

J'avais déjà penser à les implémenter dans OCILIB mais vu que quasiment personne ne les utilise....

bon, y a plus qu'a...

Citation:

---

Envoyé par Vincent Rogier

J'avais déjà penser à les implémenter dans OCILIB mais vu que quasiment personne ne les utilise....

---

Comment ca se fait que personne ne l'utilise? Existe t'il d'autres mecanismes afin de gérer ma demande? Spécifique à chaque langage de programmation/librairie?

Mon problème semble être relativement basique, qd un client met à jour une table, tous les autres veulent être immédiatement au courant...:roll:

Citation:

---

Envoyé par escafr

Comment ca se fait que personne ne l'utilise? Existe t'il d'autres mecanismes afin de gérer ma demande? Spécifique à chaque langage de programmation/librairie?

Mon problème semble être relativement basique, qd un client met à jour une table, tous les autres veulent être immédiatement au courant...:roll:

---

vu que ca a été introduit en 9i... peu de gens ont pris l'habitude de les utiliser...

Bon, en tout cas, c'est simple à intégrer donc prévu pour OCILIB 3.1.0 ou 3.2.0...

Très bien, je te remercie pour ton aide.

Bon, j'en profite un peu...

Je suis intéressé pour refaire un bench entre OTL et OCILIB.

J'avais fait un il y a quelques mois (mais peut être pas forcément partial on sait jamais..) ou OCILIB était beaucoup plus rapide et moins gourmand de OTL (surtout pour les binds ou OTL bufferise tout, STL oblige, et sur les opérations de bulk (array interface))...

Puisque tu utilises donc OTL (et donc habitué), je serai preneur pour faire un bench entre du code applicatif OTL bien fait et OCILIB.

Si tu as un tout petit peu de temps pour me fournir des exemples concrets OTL ou pour se mettre d'accord sur un jeu de test, je suis super preneur.

Je veux bien t'aider sur un jeu de test, mais bon, pour moi la grosse limite de ta lib (que je ne connais pas du tout, juste regarder rapidement) c'est:

- "est écrite en pur ISO C avec un support natif Unicode en ISO C"

Et moi je veux du C++.

Maintenant je suis très loin d'être un expert OTL car mes connaissances oracle sont limitées mais si tu as besoin d'un avis d'un utilisateur d'OTL qd à l'objectivité de tes tests, je vais bien te filer un coup de main.

EDIT: "# est le wrapper OCI le plus complet disponible" en C, car OTL semble faire plus de chose non, d'après ce que tu me dis?!

Je ne cherche pas à te convaincre... ;)

Je te contacte par mp pour le jeu de test :D

Tu vois l'interface C comme une limite, moi non.

Je ne cherche pas à targeter les dévelopement Oracle / C++...
OTL est une très bonne librairie C++.

Pourquoi je ne vois pas le cote C comme une limite ?

Car seul le C permet un interface générique permettant des bindings et donc des utilisations quasiment dans tous les langages existants. Des bindings objective C, erlang, BlitzBasic, drivers Qt ont été développés au dessus de OCILIB. Donc pour moi c'est pas une limite, au contraire...

De plus, même si OTL est une très bonne librairie, elle souffre des inconvénients des libs C++ construites sur des lib C (OCI est une lib C) : bufferisation obligatoire des strings, des binds, etc... Donc plus de mémoire et perte de performances.

OCILIB a les même perfs à (99, 999999%) que du code OCI direct.

Et pas d'application C++ utilise ocilib même si cela n'est pas cible initiale...

Pour en revenir à OTL, ses plus grosses lacunes à ajouter à celles mentionnées plus haut sont :

• aucun support pour les objet (user types, collections, ref, ...)
• pas possible de charger en dynamique les libs oracle

Son avantage principal : un header !

a+

Triste nouvelle:

Database Change Notification n'est dispo que pour Oracle 10g.
Et je suis sur Oracle 9i sans possibilité d'upgrade évidement.

Le sujet est donc réouvert...

MDM!:evilred: