[sql] [as400] [transaction]

Bonjour,
Pour régler un problème d'accès concurrent, je me suis interessé au merveilleux monde des transactions.
Hélas je ne trouve rien sur l'as400, et j'ai l'impression que la syntaxe est différend d'un SGBD à l'autre.

Je me connecte en PHP via les divers odbc à l'as400 afin de réaliser des requêtes sur des fichiers.
J'ai un problème d'accès concurrent sur un compteur à incrémenter qui n'est apparu qu'avec la montée en charge de l'appli.

Je suis bien embêté car je ne trouve rien sur le transactionnel avec un as400.
Est ce possible?

Merci d'avance!

Citation:

---

Envoyé par eizo

Pour régler un problème d'accès concurrent, je me suis interessé au merveilleux monde des transactions.
Hélas je ne trouve rien sur l'as400, et j'ai l'impression que la syntaxe est différend d'un SGBD à l'autre.

---

Oui, car les transactions sont implémentés dans les langages procéduraux, propres à chaque SGBD, mais ce n'est en aucun cas du SQL.

Quel est le SGBD avec lequel tu travailles ? DB2 ?

XO ce que vous dites est complétement faux !!!!

La syntaxe de la norme SQL2 (1992) proposait que la connexion demarre et une transaction et que celle ci se termine par un ordre COMMIT [WORK] ou ROLLBACK [WORK].

La version SQL:1999 à rajouter les principes d'autocommit et donc la possibiliter de gérer des transactions explicite avec BEGIN WORK ou START TRANSACTION.

Ces ordre fonc partie du TCL (Transaction Control Language) sous ensemble de SQL qui s'intéresse à la gestion des transactions. Il comprend aussi l'ordre SET TRANSACTION ISOLATION LEVEL ...


A +

Citation:

---

Envoyé par SQLpro

XO ce que vous dites est complétement faux !!!!

---

Tout à fait :oops:

Mea Culpa, je ne ferai plus de réponses le lundi matin ...

Le monde de l'acces concurrent est passionant ;)

La solution de SQLPro est la plus sure, cependant elle fait chuter de maniere significative les performances du SGBDR, en effet, en mode serializable, les requetes sont effectuées comme si elles etaient lancées les unes apres les autres (d'ou le nom !! :))

Mais la securité des données a t elle un cout ??
Je ne le pense pas, et je crois que SQLPro doit penser comme moi ;)

Tu peux aussi verrouiller au niveau de l'enregistrement (par un select for Update), mais ceci ne fonctionnera pas avec des agrégats, et peut donner lieu a des interblocages

Ex :

Select * from mytable where champ1=1 for update [A]
Select * from mytable where champ1=2 for update [B]
Select * from mytable where champ1=2 for update [A]
Select * from mytable where champ1=1 for update [B]

Ni [A], ni [B] ne peuvent continuer car ils sont en situation d'interblocage.

Le select * from MyTable for update peut etre une solution, mais la encore, ne pas perdre de vue le cout de verrouillage d'une table entiere.
Si la requete transactionnelle qui suit n'est pas trop longue alors ca peut etre une solution.

Peut etre que SQLPro me corrigera sur ce que j'ai ecrit ;)
J'espere t'avoir un peu eclairer

Bon Courage

Le forçage d'un verouillage peut souvent s'avérer pire que le mal.

Pour utiliser un compteur le plus sûr est d'utiliser une table de compteur. En effet le SELECT MAX(...) + 1 va devenir de plus en plus lourd et amener de plus en plus de contention au fur et à mesure de l'augmentation de la volumétrie des données, par ce qu'il vous un verrou exclusif sur toute la table.

Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/clefs/

A +