Discussion :

[khlaifimed]

Bonjour tout le monde,

S'il vous plait, y a t il un moyen pour faire commit d'une opération de USER_1 par un autre utilisateur USER_2

Exemple :
USER_1 fait une insertion dans la table table_1 sans commit ;
USER_2 fait le commit pour la session du USER_1


Merci d'avance

[Ikebukuro]

Salut,

Est-ce que tu pourrais détailler ton besoin?
Je comprends ce que tu veux faire, mais à quoi ça sert que ce soit USER_2 qui COMMIT plutôt que USER_1?

Dans la doc Oracle et sur les forums je n'ai trouvé aucune solution à ta question, tout le monde dit que c'est impossible.

[Scriuiw]

Je ne suis pas un expert DBA mais cela va à l'encontre complète du fonctionnement d'un SGBD.
- Comment garantir l'intégrité des données si un COMMIT "aveugle" peut être exécuté par un tiers qui se trouve en dehors de la transaction ?
- Comment s'assurer que le traitement est terminé et complet si un COMMIT "'externe" intervient (INSERT/UPDATE/DELETE en cours) ?

[khlaifimed]

bonjour Ikebukuro, merci pour votre reponse.

Je suis en train de développer un batch C qui utilise des bibliothèques tiers BSCS.
Vu mon code et adaptation, j'ai besoin d'ouvrir deux sessions :
- Dans la première session je fait l'insertion dans la table
- Dans la deuxième session je ferai le COMMIT de l'insertion effectué dans session 1

j'ai déjà effectué des recherche, j'ai trouvé un démarche avec package dbms_xa mais je n'ai pas pu le comprendre

[Ikebukuro]

Tu n'as pas répondu à ma question
Tu me dis que peut-être ce que tu recherches est possible avec dbms_xa MAIS tu n'expliques pas POURQUOI il te faut deux sessions.

"Vu mon code et adaptation, j'ai besoin d'ouvrir deux sessions " : pourquoi deux sessions? pourquoi cela ne peut-il pas être fait dans une seule session?

[khlaifimed]

la solution standard BSCS est à chaque fichier reçue, je doit une session et la fermer à la fin du traitement de fichier.
et vu les contraintes techniques (firewall, architecture serveur, release BSCS ... ), la connexion/reconnexion rend le performance catastrophique
D'ou j'ai l'idée de faire une 2 sessions fixes (1 pour insertion -> enclenche la 2eme -> commit)

[khlaifimed]

bonjour Scriuiw ,
les deux process seront en attente mutuelle pour i'insertion/ commit

[Ikebukuro]

Je ne pense pas que ce que tu veuilles faire soit possible sous Oracle.

En outre ta phrase "vu les contraintes techniques (firewall, architecture serveur, release BSCS ... ), la connexion/reconnexion rend le performance catastrophique" m'étonne car ce que tu veux faire dans une session (INSERT et COMMIT) n'a aucune raison de poser des problèmes techniques, c'est du SQL très basique.

[tbc92]

C'est bizarre. Tu dis que tu as des problèmes de performances en te connectant /déconnectant à chaque transaction, et pour solutionner cela, tu envisages de faire encore plus de connexions/déconnexions ?

Tu te connectes une fois, tu fais tes insert /update, et tu fais ton commit. A la fin tu te déconnectes, ou éventuellement tu ne te déconnectes pas si tu as un autre fichier à traiter ; où est le problème de performance ?

[khlaifimed]

bonjour tbc92 et merci pour votre reponse

le but est eviter la connexion/deconnexion , et comme j'ai dit que j'utilises des routines tiers et ces routines m'oblige de connect/disconnect
alors j'ai adapté le code pour faire 2 sessions pertinentes:
- dans la 1ere j'appèle les routines tiers pour l'insertion sans appeler celle de commit et clôture
- dans la 2eme, je fait le commit de la 1ere session

[Ikebukuro]

Est-ce qu'il serait possible de voir ton code? Du moins comment tu fais le COMMIT dans la première session depuis la deuxième session?
Tu utilises des procédures Oracles en PL/SQL finalement?

[khlaifimed]

Bonjour Ikebukuro, voila le code que j'ai trouvé dans un blog ou on utilise le package dbms_xa et je veux l'utiliser comme exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
-- Session 1 starts a transaction and does some work.
DECLARE
 rc  PLS_INTEGER;
 oer PLS_INTEGER;
 xae EXCEPTION;
BEGIN
  rc := dbms_xa.xa_start(dbms_xa_xid(123), dbms_xa.tmnoflags);
 
  IF rc != dbms_xa.xa_ok THEN
    oer := dbms_xa.xa_getlastoer();
    dbms_output.put_line('ORA-' || oer || ' occurred, XA_START failed');
    RAISE xae;
  ELSE
    dbms_output.put_line('XA_START(new xid=123) OK');
  END IF;
 
  UPDATE employees
  SET salary = salary * 1.1
  WHERE employee_id = 100;
 
  rc := dbms_xa.xa_end(dbms_xa_xid(123), dbms_xa.tmsuspend);
 
  IF rc != dbms_xa.xa_ok THEN
    oer := dbms_xa.xa_getlastoer();
    dbms_output.put_line('ORA-' || oer || ' occurred, XA_END failed');
    RAISE xae;
  ELSE
    dbms_output.put_line('XA_END(suspend xid=123) OK');
  END IF; 
EXCEPTION
  WHEN OTHERS THEN
    dbms_output.put_line('XA error('||rc||') occurred, rolling back the transaction ...');
    rc := dbms_xa.xa_end(dbms_xa_xid(123), dbms_xa.tmsuccess);
    rc := dbms_xa.xa_rollback(dbms_xa_xid(123));
 
    IF rc != dbms_xa.xa_ok THEN
      oer := dbms_xa.xa_getlastoer();
      dbms_output.put_line('XA-' || rc || ', ORA-' || oer ||' XA_ROLLBACK does not return XA_OK');
      raise_application_error(-20001, 'ORA-' || oer ||' error in rolling back a failed transaction');
    END IF;
    raise_application_error(-20002, 'ORA-' || oer ||' error in transaction processing, transaction rolled back');
END;
/
 
-- Session 2 commits the transaction
DECLARE
 rc  PLS_INTEGER;
 oer PLS_INTEGER;
 xae EXCEPTION;
BEGIN
  rc := dbms_xa.xa_commit(dbms_xa_xid(123), TRUE);
 
  IF rc != dbms_xa.xa_ok THEN
    oer := dbms_xa.xa_getlastoer();
    dbms_output.put_line('ORA-' || oer || ' occurred, XA_COMMIT failed');
    RAISE xae;
  ELSE
    dbms_output.put_line('XA_COMMIT(commit xid=123) OK');
  END IF;
EXCEPTION
  WHEN xae THEN
    dbms_output.put_line('XA error('||rc||') occurred, rolling back the transaction ...');
 
    rc := dbms_xa.xa_rollback(dbms_xa_xid(123));
 
    IF rc != dbms_xa.xa_ok THEN
      oer := dbms_xa.xa_getlastoer();
      dbms_output.put_line('XA-' || rc ||', ORA-' || oer ||' XA_ROLLBACK does not return XA_OK');
      raise_application_error(-20001, 'ORA-' || oer ||' error in rolling back a failed transaction');
    END IF;
      raise_application_error(-20002, 'ORA-' || oer ||' error in transaction processing, transaction rolled back');
END;
/

[mnitu]

bonjour tbc92 et merci pour votre reponse

le but est eviter la connexion/deconnexion , et comme j'ai dit que j'utilises des routines tiers et ces routines m'oblige de connect/disconnect
alors j'ai adapté le code pour faire 2 sessions pertinentes:
- dans la 1ere j'appèle les routines tiers pour l'insertion sans appeler celle de commit et clôture
- dans la 2eme, je fait le commit de la 1ere session

Et pour quel raison avez vous-besoin de faire commit dans la deuxième session ? Je veux dire pourquoi ne continuez-vous à appeler les routines de la de première session jusqu'au moment où vous avez fini de traiter tous vos fichier avec les routines tiers ?

[khlaifimed]

Bonjour mnitu,

l'appel de routine tiers de commit = fin de session
Je cherche actuellement une solution pour ne pas fermer la session

[mnitu]

Oui je pense que j'ai compris cela. Mais ma question essai de vous suggérer de travailler de la façon suivante:

• vous ouvrez la première session et vous insérez toutes vos données sans faire commit, éventuellement dans une table de travail
• quand vous avez fini vous faite commit (= fin session)
• puis vous (ré)ouvrez la session et vous traitez les données chargées à la première étape

[SQLpro]

bonjour Ikebukuro, merci pour votre reponse.

Je suis en train de développer un batch C qui utilise des bibliothèques tiers BSCS.
Vu mon code et adaptation, j'ai besoin d'ouvrir deux sessions :
- Dans la première session je fait l'insertion dans la table
- Dans la deuxième session je ferai le COMMIT de l'insertion effectué dans session 1

j'ai déjà effectué des recherche, j'ai trouvé un démarche avec package dbms_xa mais je n'ai pas pu le comprendre

Les transactions étant par définition et nature séquentielles on ne peut pas paralléliser leur exécution dans deux sessions différentes. La seule solution (très tordu et auquel je n'ai pas de code a donner sauf à modifier les bibliothèques système du niveau CLI) est de reprendre la main sur la session 1 par la session 2, autrement dit effectuer un écrasement logique... Bonne chance pour un tel codage !

Entre nous je ne voit aucun intérêt de faire cela. Pire je pense que c'est d'une haute stupidité ! C'est pourquoi il serait intéressant que vous nous donniez enfin les explications fonctionnelles et non pas une vague description pseudo algorithmique.

A +