Bof, vu qu'on parlais de Generix hier, pour information, chez Generix, le 0 janvier existe.
C'est la date du report des à nouveaux comptable de l'année précédente.
Et si on les gère tous les mois... ben le 0 février, le 0 mars, le 0 avril... existent aussi 8O
Généralement certains développeurs bloquent l'accès à la ligne via l'insertion de son ID dans une table temporaire et bloque n'importe quelle update (voire même de faire la select parfois).Citation:
Envoyé par SQLpro
je sais pas si c'est une bonne solution ou pas, j'aime bien savoir votre avis
Le problème du blocage c'est de gérer l'absence de déblocage (panne, abandon, etc).
Une autre solution possible est de gérer une information (TIMESTAMP de modification par exemple) pour la ligne en cours de modification; de la conserver pour l'utilisateur en cours (contexte ou IHM non affichée), puis de la relire à nouveau avant de modifier la ligne et de comparer si elle et si elle a changé, et si c'est le cas d'émettre un message du style " Données modifiées entre temps ".
En fait, surtout, tous ces mécanismes sont là pour :
- pallier des limitations des SGBD dans les années 80
- pallier au manque de formation et de rigueur des développeurs depuis
Les SGBD depuis les années 2000 savent tous gérer différents niveau de lock (lecture, mise à jour, etc.) jusqu'à la ligne, voire à la donnée elle-même au sein d'une ligne.
Ainsi, réinventer des usines à gaz hors SGBD ça résulte d'une conception dinosauresque, soit de part son âge, soit de celui de la formation du concepteur.
Dans tous les cas, à ce jour, ça n'a plus aucune utilité, à un détail près, qui n'est pas des moindres : le web ne sait pas (enfin, si, mais avec un coût exorbitant en termes de ressource, et donc jamais utilisé) conserver un handle sur les données entre deux chargement de pages. C'est d'autant plus vrai avec tous les services qui deviennent stateless.
Bref, l'évolution de l'informatique (tout web) nous renvoie aux années 70 avec des utilisations complètement absurdes des bases de données.
=> Et c'est ainsi qu'on a vu débarquer tous les NoSql et autre inventions SGBD-dégénérésantes qui n'ont fait qu'un retour en arrière incroyable.
Moi je vote, et je promet de beaux jours au séquentiel indexé, c'est trop de la balle.
Bien sûr que les SGBD modernes savent gérer les verrous et ça tout le monde le sait ...Citation:
Envoyé par StringBuilder
On se place juste dans l'hypothèse d'un échange avec l'IHM et là les verrous sont bien libérés car les THREAD sont terminés ...
Et là on fait comment ?
Pas forcément.
Les SGBD sont faits à la base pour conserver ces verrous.
On peut par exemple faire ceci avec SQL Server :
=> Tant que la transaction n'est pas terminée (commit ou rollback) alors la ligne est inaccessible (lock exclusif).Code:
2
3
4
5
6
=> Tant que la transaction n'est pas terminée (commit ou rollback) alors la ligne est lisible mais ne peut pas être mise à jour (lock partagé).Code:
2
3
4
5
6
Il y a tout un tas de granularité de lock possible et tout un tas de scope aussi.
https://docs.microsoft.com/en-us/sql...l-server-ver15
Dans une IHM classique, dès qu'on ouvre une fiche en modification, on fait un SELECT avec un UPDLOCK ou XLOCK de façon à ce que personne ne puisse venir modifier les données, voir même les utiliser.
L'avantage (mais aussi l'inconvénient) c'est que mise à part avec des hints particulier qui permettent de passer outre certains niveaux de lock, il est impossible par erreur d'ignorer un verrou au niveau base, alors qu'un verrou géré au niveau métier peut largement être ignoré, ne serait-ce que par un traitement externe qui n'utilise pas ton objet métier).
Le type qui sirote son café devant l'écran ou va satisfaire un besoins pressant ou qui s'endort devant l'affichage, va faire en sorte que le SGBD garde les verrous au delà de l'échange Serveur / IHM.Citation:
Envoyé par StringBuilder
Je ne sais pas où tu travailles mais ce qui est sûr, c'est que dans la Banque où je suis et où on traite en période de pointe 1200 / 1300 transactions par seconde, on ne fait jamais cela.
Au détail près que ce dont tu parles n'a rien à voir.
Les 1300 transactions par seconde ne concernent pas :
- des données saisies depuis une IHM
- des données de référence
=> les mouvements bancaires sont de nouvelles lignes, donc tu peux bien les locker autant de temps que tu veux, de toute façon ça n'impacte personne, sauf si par hasard on souhaite débiter et créditer en même temps le même compte…
Ensuite, dans une banque, en effet, les verrous sont tellement mal gérés que généralement, tout changement (retrait, encaissement, virement, modification de contrat) n'est pris en compte que plusieurs heures, voir jours après leur saisie : ils sont saisis dans une base séparée, puis déversés en masse périodiquement dans la base "réelle" : il n'y a que dans une banque qu'on va te laisser dépasser allègrement le plafond de ton découvert autorisé, puis subitement, à partir de minuit 12 le lendemain, bloquer toutes les transactions…
Heureusement que les bases de gestion de stocks ne sont pas gérées comme ça…
Sinon, à part le troll, tout verrou est accompagné d'un timeout… Il suffit que l'IHM coupe la connexion au bout d'un temps imparti pour que la pause pipi ne gêne personne.Citation:
- Hey, Régis ! Pourquoi t'as laissé partir le camion à vide ?
- T'inquiète, y'a le magasinier qui revient avec le Fenwick, il va le rattraper !
Trouvé dans un document SQL Server :
http://https://docs.microsoft.com/fr...ql-server-2014Citation:
Aucune interaction utilisateur dans les transactions
Évitez d'écrire des transactions comprenant une interaction utilisateur, car la vitesse d'exécution des traitements sans intervention de l'utilisateur est beaucoup plus rapide que la vitesse à laquelle un utilisateur doit répondre manuellement aux requêtes telles que la demande d'un paramètre requis par une application. Par exemple, si une transaction attend une entrée de la part de l'utilisateur, et si ce dernier va déjeuner ou rentre chez lui pour le week-end, l'utilisateur empêche la transaction de se terminer. Ceci dégrade les performances du système, car tous les verrous détenus par la transaction ne sont libérés qu'une fois la transaction validée ou restaurée. Même si une situation de blocage ne se produit pas, toutes les autres transactions en attente de la même ressource sont bloquées, en attente de la fin de la transaction.
Ce qui semble possible avec SQL Server (conservation des verrous au delà des échanges) ne le serait pas, à mon sens, avec Db2 for z/OS.
Non, c'est généralement catastrophique... En effet, en cas de fermeture de l'application, si l'utilisateur ne passe pas par le bon bouton, ce verrou fonctionnel ne sera jamais levé et ne pourra plus être accessible !Citation:
Envoyé par erpWorld
C'est pour lutter contre ce genre d'imbécilité qu'en 1976, l'équipe de Gray au sein d'IBM propose un mécanisme automatique de verrouillage fin basé sur les prédicat des requêtes ce qui conduira à l'implémentation du concept de journal des transaction qui automatise le tout au sein du SGBDR !
A lire :
http://jimgray.azurewebsites.net/pap...tem%20cacm.pdf
A +
Oui, mais comme tu l'as cité, il est "déconseillé".Citation:
Envoyé par Luc Orient
Effectivement, tu vas pas lancer un recalcul de la balance âgée en demandant à l'utilisateur de valider ligne à ligne... on est bien d'accord.
En revanche, lors de la saisie d'une sortie de stock, que tu verrouilles la fiche de stock en attendant la validation définitive de l'utilisateur, c'est juste normal : si tu ne verrouilles rien, ton stock est faux, puisqu'il est dans l'état où à priori on n'en a plus, mais en fait peut-être que si.
ça dépend juste du niveau d’isolation que tu utilises.Citation:
Envoyé par Luc Orient
Si tu utilise le niveau d’isolation READ COMMITTED, alors les données lues au début du traitement peuvent voir leur valeurs différer plus tard dans le traitement transactionnel. les verrous étant libéré juste après que la lecture soit faite par l'ordre SQL au sein de la transaction.
Si tu utilise le niveau d’isolation REPEATBLE READ, le système assure la stabilité des données en verrouillant les lignes dès la première lecture et ce jusqu’à la fin du traitement transactionnel.
Si tu utilise le niveau d’isolation SERIALIZABLE, le système assure la stabilité des données en verrouillant les tables (en faites tous les lignes qualifiées d'après les prédicats de recherche des requêtes en empêchant l'apparition de nouvelles lignes qualifiées) dès la première lecture et ce jusqu’à la fin du traitement transactionnel.
Donc, même pour un stock, inutile de verrouiller à la main, il suffit d'utiliser le bon niveau d’isolation.
À me relire, et tester :
https://sqlpro.developpez.com/isolation-transaction/
ATTENTION ceci est valable en verrouillage pessimiste. En optimiste le niveau REPATABLE READ n'a pas de sens puisque l'on travaille sur une copie dont les lignes sont stable pendant toute la durée du traitement transactionnel. Mais il y a d'autres inconvénient dans le mode optimiste, telle que la perte de mise à jours...
Pour info, je rédige mon nouveau livre sur SQL et je parle de cet article :
http://people.csail.mit.edu/tdanford...onsistency.pdf
en 1976, la solution de verrouillage fin et l'intégration de la récupération (RECOVERY) des données était trouvé par Jim Gary et son équipe...
A +
Et que se passe-t- il si le TIMEOUT est déclenché ?Citation:
Envoyé par StringBuilder
Si le timeout de connexion est déclenché, alors la connexion est fermée, et la transaction rollbackée. Donc verrou libéré.
Le timeout ne concerne que l'accès primitif aux données du SGBDR, pas le temps de la transaction. Donc, si timeout il y a, la transaction n'a pas encore démarré, car au niveau physique il n'y réellement transaction que lorsque le premier verrou a été posé !Citation:
Envoyé par Luc Orient
D'autre part :
.. donc même pas, car la transaction n'a pas physiquement démarrée. D'ailleurs le message d'erreur staandard est clair, il parle de timeout et non pas de rollbacKCitation:
Envoyé par StringBuilder
A +
Pour en terminer avec cette histoire de contrôle de saisie... rappel de la règle de Codd n° 10 :
Rule 10: Integrity independence:
Integrity constraints specific to a particular relational data base must be definable in the relational data sublanguage and storable in the catalog, not in the application programs.
Que j'ai traduit dans mon nouvel ouvrage à paraître sur SQL :
Règle 10 – Indépendance d'intégrité
Les contraintes d'intégrité spécifiques à une base de données relationnelle particulière doivent être définies par le sous-langage relationnel et stockées dans le catalogue, et non dans les programmes d'application.
A +
Hmpf, faut que j'arrête de bosser sur plusieurs truc à la fois...
En effet, le timeout de connexion ne concerne que le délai avant l'abandon de l'établissement de connexion.
Tout comme le timeout de commande ne concerne que le délai d'exécution d'une requête (ou d'un lot).
En fait, le programme doit faire l'inverse : clore régulièrement les connexions ouvertes mais inactives (pause pipi).
La fermeture de la connexion à pour effet d'annuler toute transaction en cours. https://docs.microsoft.com/en-us/dot...nnection_Close
PS : On parle de connexions en terme de pool de connexions. Quand on ferme la connexion ici, elle n'est pas réellement fermée côté SQL Server, il n'y a pas d'impact sur les performances.
Je ne comprends pas là ... Avant l'échange, il y a pose de verrou(s) ou pas ?Citation:
Envoyé par SQLpro
Les verrous d'intention sont choisis au moment du bind et posés dès le début de programme
Les verrous réels, eux, sont posés lors de l'exécution de l'ordre.
j'aurais du dire, verrou d'écriture !!!!Citation:
Envoyé par Luc Orient
A +