Quelqu'un peut-il fournir une explication simple (mais pas plus simple que possible) d'une transaction appliquée à l'informatique (même si elle est copiée à partir de Wikipedia)?
Quelqu'un peut-il fournir une explication simple (mais pas plus simple que possible) d'une transaction appliquée à l'informatique (même si elle est copiée à partir de Wikipedia)?
Réponses:
Une transaction est une unité de travail que vous souhaitez traiter comme «un tout». Cela doit se produire dans son intégralité ou pas du tout.
Un exemple classique est le transfert d'argent d'un compte bancaire à un autre. Pour ce faire, vous devez d'abord retirer le montant du compte source, puis le déposer sur le compte de destination. L'opération doit réussir pleinement. Si vous vous arrêtez à mi-chemin, l'argent sera perdu, et c'est très mauvais.
Dans les bases de données modernes, les transactions font également d'autres choses - comme s'assurer que vous ne pouvez pas accéder aux données qu'une autre personne a écrites à mi-chemin. Mais l'idée de base est la même: les transactions sont là pour garantir que , quoi qu'il arrive, les données avec lesquelles vous travaillez seront dans un état raisonnable . Ils garantissent qu'il n'y aura PAS de situation où l'argent sera retiré d'un compte, mais pas déposé sur un autre.
Une transaction est une manière de représenter un changement d'état. Les transactions ont idéalement quatre propriétés, communément appelées ACID:
Voir l' entrée ACID de Wikipedia pour plus de détails.
Bien que cela soit généralement appliqué aux bases de données, cela n'est pas obligatoire. (En particulier, voir Mémoire transactionnelle logicielle .)
Voici une explication simple. Vous devez transférer 100 dollars du compte A vers le compte B.Vous pouvez soit faire:
accountA -= 100;
accountB += 100;
ou
accountB += 100;
accountA -= 100;
Si quelque chose ne va pas entre la première et la deuxième opération de la paire, vous avez un problème - soit 100 dollars ont disparu, soit ils sont apparus de nulle part.
Une transaction est un mécanisme qui vous permet de marquer un groupe d'opérations et de les exécuter de telle manière que soit elles s'exécutent toutes (validation), soit l'état du système sera comme si elles n'avaient pas du tout commencé à s'exécuter (rollback).
beginTransaction;
accountB += 100;
accountA -= 100;
commitTransaction;
transférera 100 dollars ou laissera les deux comptes dans l'état initial.
"Une série d'instructions de manipulation de données qui doivent soit se terminer complètement, soit échouer complètement, laissant la base de données dans un état cohérent"
Une transaction est une séquence d'une ou plusieurs opérations SQL qui sont traitées comme une unité.
Plus précisément, chaque transaction semble s'exécuter de manière isolée, et de plus, si le système échoue, chaque transaction est soit exécutée dans son intégralité, soit pas toutes.
Le concept de transaction est motivé par deux préoccupations totalement indépendantes. L'une concerne l'accès simultané à la base de données par plusieurs clients, et l'autre concerne le fait d'avoir un système résilient aux pannes système.
La transaction prend en charge ce que l'on appelle les propriétés ACID:
http://en.wikipedia.org/wiki/Database_transaction
http://en.wikipedia.org/wiki/ACID
ACID = A tomicity, C onsistency, I solation, D urabilité
Lorsque vous souhaitez que plusieurs ressources transactionnelles soient impliquées dans une seule transaction, vous devrez utiliser quelque chose comme une solution de validation en deux phases . XA est assez largement pris en charge.
Je dirais qu'une définition du «traitement des transactions» serait plus utile, car elle couvre les transactions en tant que concept en informatique.
De wikipedia:
En informatique, le traitement des transactions est un traitement de l'information qui est divisé en opérations individuelles et indivisibles, appelées transactions. Chaque transaction doit réussir ou échouer en tant qu'unité complète; il ne peut pas rester dans un état intermédiaire.
http://en.wikipedia.org/wiki/Transaction_processing#Implementations
En plus des réponses ci-dessus, il convient de noter qu'il n'y a, au moins en théorie, aucune restriction quant au type de ressources impliquées dans une transaction.
La plupart du temps, il ne s'agit que d'une base de données, ou de plusieurs bases de données distinctes, mais il est également concevable qu'une imprimante participe à une transaction, et peut provoquer l'échec de cette transaction, par exemple en cas de bourrage papier.
La transaction peut être définie comme un ensemble de tâches considérées comme une unité de traitement minimale. Chaque unité de traitement minimale ne peut pas être divisée davantage.
Les opérations principales d'une transaction sont la lecture et l'écriture.
Toute transaction doit contenir quatre propriétés communément appelées propriétés ACID dans le but d'assurer l'exactitude, l'exhaustivité et l'intégrité des données.
Je pense qu'une transaction est une action atomique en termes de SGBD.
cela signifie qu'il ne peut pas être séparé. oui, dans une transaction, il peut y avoir plusieurs instructions à exécuter par le système. mais ils sont liés ensemble pour terminer une seule tâche de base.
par exemple. vous devez traverser un pont (traitons cela comme une transition), et pour ce faire, disons, vous avez besoin de 100 étapes. dans l'ensemble, ces étapes ne peuvent pas être séparées. lorsque vous en avez fait la moitié, il n'y a que deux choix pour vous: continuer à tous les terminer et revenir au point de départ. c'est exactement comme le résultat d'une transaction: succès (validé) et échec (restauration)
La transaction est une unité indivisible de traitement des données -Toutes les transactions doivent avoir les propriétés ACID:
c'est-à-dire: l'atomicité, la cohérence, l'isolement et la transaction durable sont tout ou rien, mais pas intermédiaires (cela signifie que si vous transférez votre argent d'un compte à un autre compte, un compte doit perdre autant et un autre doit gagner ce montant, mais si vous transférez de l'argent d'un compte et un autre compte est toujours vide qui ne sera pas une transaction)