Pools, connexions et sessions BDD [Résolu]

[Jeweller]

Bonjour!
En vue de répondre aux normes FDA, nous souhaitons tracer toutes les modifications apportées aux données de notre appli. Pour effectuer cela, nous mettons en place des triggers (attendez avant de sauter de votre chaise! ) qui journalisent de cette façon toutes les opérations effectuées y compris celles qui ne sont pas faite directement pour notre appli (certains de nos utilisateurs se connectent avec Access par exemple, voir des appli propriétaires, pour extraire et/ou modifier des données).
Ces triggers doivent etre capable d'indiquer quel est l'utilisateur logique (login interne à notre application) qui a effectué telle opération. Pour cela dans l'appli "windows", on joint le compte utilisateur et la session SQLServer ou Oracle. En mode connecté, pas de probleme.
Dans l'application XMLRAD ca se complique.... j'ai 4 pool et en plus pour chaque xmlmodule, potentiellement une connexion à la BDD (partage de code) (d'ailleurs j'ai une question à ce sujet que je soulèverais plus tard...). Donc pour un user sur l'appli je vais avoir plusieurs sessions BDD et entre chaque requete HTTP je suis biensur susceptible d'avoir plusieurs users différents.

Pour les courageux qui m'ont lu jusque la, voici ma question:
Ou mettre mon code qui me permettra de faire le lien entre la session et l'utilisateur? Je ne peux pas faire cela trop tot (dans le dispatch) car j'ai besoin de connaitre qu'elle sera exactement la session BDD qui sera utilisée. Je ne sais pas si c'est possible ni si c'est centralisable (si ca l'est pas, je le ferais pas )


Michael

[Jeweller]

Allez, la suite directement:
Actuellement j'ai un ADOConnection par XMLmodule. Cela car j'ai besoin de connecter un ensemble d'objets basé sur des ADOQuery classiques pour effectuer un certain nombre d'opérations (ca représente plus d'une centaines de méthodes dans pleins de datamodules... trop délicat et couteux de les migrer en dacquery aujourd'hui... même si dans l'absolu ce serait l'idéal!).
J'aimerais plutot que de gérer cela par XMLModule, le faire par Pool, ce qui me parait plus logique. Comment puis-je créer un objet ADOConnection par instance de pool (pour le partager ensuite aux modules du pool)? Y a t-il un "endroit" privilégié, sorte de threadvar ou qqch comme ca ? J'aimerais gérer cela proprement.

Michael

[RDM]

Envoyé par Jeweller

Ou mettre mon code qui me permettra de faire le lien entre la session et l'utilisateur? Je ne peux pas faire cela trop tot (dans le dispatch) car j'ai besoin de connaitre qu'elle sera exactement la session BDD qui sera utilisée. Je ne sais pas si c'est possible ni si c'est centralisable (si ca l'est pas, je le ferais pas )

j'ai un peu du mal a visualiser ce que t tu veux , et de quelles informations tu as besoin.
De toutes facons il faut se tourner vers les evenénements XMLApplication ou XMLCollection.
les événements XMLApplication sont déclenchés en dehors des XMLCollections donc tu n'as normalement pas encore accès aux ressources des XMLcollections et donc pas d'accès aux BDD.
les événements XMLCollection sont déclenchés une fois que ta requête a acquis une XMLCollection et donc la tu as accès aux connexions BDD.
le XMLCollection.BeforeDispatch me semble un bon endroit en général.

[RDM]

Envoyé par Jeweller

Allez, la suite directement:
Actuellement j'ai un ADOConnection par XMLmodule. Cela car j'ai besoin de connecter un ensemble d'objets basé sur des ADOQuery classiques pour effectuer un certain nombre d'opérations (ca représente plus d'une centaines de méthodes dans pleins de datamodules... trop délicat et couteux de les migrer en dacquery aujourd'hui... même si dans l'absolu ce serait l'idéal!).
J'aimerais plutot que de gérer cela par XMLModule, le faire par Pool, ce qui me parait plus logique. Comment puis-je créer un objet ADOConnection par instance de pool (pour le partager ensuite aux modules du pool)? Y a t-il un "endroit" privilégié, sorte de threadvar ou qqch comme ca ? J'aimerais gérer cela proprement.

Michael

il te suffit de mettre ton ADOConnection dans un module central (Common) et public dans ce module puis dans tous les modules dont tu as besoin de cette ADOConnection, tu décalres une données membre du type du XMLModule Commun genre

Code :

FxmCommon: TxmCommon;

et dans le OnInitialize du module tu fais:

Code :

1
2
3
begin
  FxmCommon := XMLCollection.GetModule('xmCommon') as TxmCommon;
end;

pour l'initialiser correctement
et après dans ton code:

Code :

FxmCommon.ADOConnection.Open;

[Jeweller]

Pour le point 2 (xmCommun), c'est excatement ce que je cherchais! J'avais pas réussi à le matérialiser, Merci!

Pour le premier point (session BDD), je vais faire un peu autrement et me baser sur le xmCommun de façon à référencer l'ensemble des sessions disponibles d'entrée de jeu et passer ensuite par le OnDispatch de la collection... A voir encore, je sais pas trop... Si ca vous interesse je vous donnerais le resultat de tout ca.

Michael

[Jeweller]

et dans le OnInitialize du module tu fais:

Code :

pour l'initialiser correctement

Petit truc, XMLCollection est disponible depuis le Module et non en dehors de celui-ci (dans le initialize)... J'ai donc déplacer le GetModule dans le constructeur de celui-ci... Je vais tester de cette façon, ca devrait fonctionner aussi!

Michael

[Jeweller]

Contrairement à ce que je pensais, le GetModule ne crée pas le module... comment le créer pour chaque collection et le référencer pour que le GetModule renvoie la référence et non nil ?
Michael

[Jeweller]

Non, au final il semblerait surtout que dans create du module, le xmlcollection ne soit pas affecté... ce qui parait logique. Le OnInitialize parait donc plus indiqué!

[Jeweller]

Question subsidiaire:
Sur un XMLModule qui est référencé dans tous les pool, il y a un composant CollectionEvent... Est ce que ses évènements réagissent pour tout les pool ou seulement pour le premier ? Autrement dit, est ce qu'un seul composant CollectionEvent est suffisant pour géré les evenements dispatch par exemple de tout les pools (si le module sur lequel il est posé est référencé dans tous les pools) ?

Michael

[RDM]

oui tout est dans la phrase "si le module sur lequel il est posé est référencé dans tous les pools"

[Jeweller]

Desole, je reviens à la charge avec l'histoire du xmCommon.
J'ai une application en mode pluggin... 2 Dll sont chargées. Dans la principale j'ai mon XMCommon qui possède les objets partagés dans chaque pool. Dans la seconde dll, (dont l'unique module est positionné sur le pool principal 'User'), j'ai aussi besoin d'accéder à ce même XmCommon... Comment faire ? Dans le OnInitialize de ce module j'ai le même code qui fait le GetModule, mais j'ai une exception Invalid Class Type (sur le "as TXmCommon")... Comment je peux m'en sortir ?

Michael

[Jeweller]

Je peux m'en sortir comme ca:

Dans le OnInitialize de tous mes modules

Code :

1
2
3
4
5
6
7
8
 
  try
     FXmComm := Module.XMLCollection.GetModule('MOS_Common') as TMOS_Common;
  except
      FXmComm := TMOS_Common.Create(nil);
      FXmComm.Name := 'MOS_Common';
      Module.XMLCollection.AddModule(FXmComm);
  end;

Une tricherie un peu bourine qui fonctionne pour la seconde dll chargée... le soucis c'est que ca m'explose à la figure quand je iisreset... je suppose que si je le crée moi même, je dois le libérer moi même... je vais tester...

Michael

[Jeweller]

Je me fais mon thread tout seul moi 8)

OnInitialize:

Code :

1
2
3
4
5
6
7
8
9
 
 SelfCreatedXmCom := false;
 try
     FXmComm := Module.XMLCollection.GetModule('MOS_Common') as TMOS_Common;
 except
      FXmComm := TMOS_Common.Create(nil);
      FXmComm.Name := 'MOS_Common';
      SelfCreatedXmCom := true;
 end;

(On pourrait utiliser le 'is')

A la destruction:

Code :

1
2
3
4
 
 if not SelfCreatedXmCom
 then FXmComm := nil
 else  FXmComm.Free;

Et ca a l'air de fonctionner...

Michael

[RDM]

oulah c'est super dangeureux tout ca.
pour les plugins les modules sont bien créés dans la même XMLCollection
seulement tu as du mettre dans ton module un uses xmCommon
ce qui a eu pour effet de compiler l'unité dans ton plugin.
Or cette unité est déjà compilé dans la DLL principale.
du coup tu as 2 TxmCommon qui sont des types incompatibles
Il faut que tu passes par un package central comme le VCLXMLxx.bpl et que les 2 DLL link sur ce package pour partager la même classe xmCommon

[Jeweller]

Mmm, pourquoi est ce que je m'en doutais....

Je risque quoi en réalité ?
Compiler XmCommon dans un paquet a peut etre l'air de rien comme ca, mais au regard de mon projet, ca se complique sérieusement...

[RDM]

la meilleure chose reste alors d'encapsuler les méthodes dont tu as besoin dans un XMLService qui sera alors invokable par un XMLCollection.execute ou une instruction Invoke

[Jeweller]

Oui, c'est une idée aussi!
Bon, au final, j'ai réussi à compiler xmCommon dans un bpl séparé... malgré les insultes de Delphi voulant rajouter tout un tas de dépendances qui ne sont pas possibles pour moi... ca fonctionne bien, la seconde dll ne pese plus que 90Ko contre plus 3Mo avant! (forcement tout est passé dans le bpl)
je pense d'ailleurs que mon architecture est bien meilleure comme ca!
Donc Merci bcp!

: J'ai encore juste un truc dont je voudrais etre sur: J'ai donc 4 pools, chacun connecte en plus de la database du framework, une adoconnection. Ainsi il y a 8 sessions ouvertes sur la base de données. En terme de licences, je suppose que MSSQL ou Oracle comptent autant de licences que d'utilisateurs potentiellement connectés à l'appli, et pas juste 1 voir 8 licences ? C'est bien ca ?

Michael

[RDM]

auparavant c'etait au nombre de session conenctés donc dans ton cas c'est bien 8, quelques soit le nombre d'utilisateur de ton application.
Au vu des archis Web voire des 3 tiers, certains editeurs ont changé leur mode de licence pour le faire par processeur ou par Mhz pour prendre compte ces nouvelles archis ou l'on ne peut plus facilement compté le nombre d'utilisateurs conenctés