Published on

November 24, 2012

Utilisation du timestamp dans SQL Server pour les applications de mise à jour asynchrones

Aujourd’hui, nous allons discuter d’un scénario courant auquel de nombreuses applications sont confrontées – la gestion de mises à jour simultanées sur une seule ligne d’une table de base de données. Cette situation se produit souvent dans les systèmes d’enchères ou toute application où plusieurs utilisateurs essaient de mettre à jour les mêmes données en même temps.

Prenons en compte un scénario où plusieurs parties font des enchères sur un article dans un système d’enchères. Pendant les dernières minutes des enchères, de nombreuses parties essaient de soumettre leurs enchères avec le même prix. Afin de garantir l’équité, l’application doit vérifier si les données originales qu’ils ont récupérées sont toujours les mêmes avant d’accepter leur nouveau prix proposé.

D’un point de vue technique, le défi consiste à permettre uniquement au tout premier utilisateur de mettre à jour la ligne, tandis que les autres utilisateurs doivent récupérer à nouveau la ligne et la mettre à jour. Verrouiller l’enregistrement n’est pas une option car cela peut créer d’autres problèmes.

Une solution possible à ce problème est d’utiliser le type de données TIMESTAMP dans SQL Server. Jetons un coup d’œil à un exemple simple :

USE tempdb
GO

CREATE TABLE SampleTable (
    ID INT,
    Col1 VARCHAR(100),
    TimeStampCol TIMESTAMP
)
GO

INSERT INTO SampleTable (ID, Col1)
VALUES (1, 'FirstVal')
GO

SELECT ID, Col1, TimeStampCol
FROM SampleTable

UPDATE SampleTable
SET Col1 = 'NextValue'

SELECT ID, Col1, TimeStampCol
FROM SampleTable

DROP TABLE SampleTable
GO

Dans cet exemple, nous créons une table avec une colonne TIMESTAMP. Lorsque nous insérons la première valeur, un timestamp est généré. Chaque fois que nous mettons à jour une valeur dans cette ligne, le timestamp est mis à jour avec la nouvelle valeur. Cela signifie que chaque fois que nous mettons à jour une valeur dans la ligne, un nouveau timestamp est généré.

Maintenant, appliquons ce concept au scénario original. Dans ce cas, plusieurs utilisateurs récupèrent la même ligne et ils ont tous le même timestamp. Avant que tout utilisateur mette à jour la ligne, il doit récupérer le timestamp de la table et le comparer avec le timestamp qu’il possède. Si les deux timestamps ont la même valeur, cela signifie que la ligne d’origine n’a pas été mise à jour et ils peuvent mettre à jour en toute sécurité la ligne avec la nouvelle valeur.

Après la mise à jour initiale, la ligne contiendra un nouveau timestamp. Toutes les mises à jour ultérieures sur la même ligne doivent également passer par le processus de vérification de la valeur du timestamp. Si le timestamp en mémoire est différent du timestamp dans la ligne, cela indique que la ligne a été modifiée et de nouvelles mises à jour ne doivent pas être autorisées.

Le type de données TIMESTAMP peut être très utile dans ce type de scénario. Il offre un moyen simple et efficace de gérer les mises à jour concurrentes sans avoir besoin de verrouiller les enregistrements.

Avez-vous d’autres suggestions ou alternatives ? Veuillez laisser un commentaire ci-dessous et je serai ravi d’en discuter dans un prochain article de blog.

Click to rate this post!
[Total: 0 Average: 0]

Let's work together

Send us a message or book free introductory meeting with us using button below.