Cache qui mélange des données

Version imprimable

15/05/2018, 11h03
Maleantes

Cache qui mélange des données

Bonjour tout le monde,

Il m'arrive un problème vraiment très bizarre et aléatoire.
J'ai un webService qui possède un module de cache (géré par un ConcurrentDictionary key/MemoryCache) pour gérer les objets génériques. Le cache fonctionne bien et ressort bien les données.

Cependant je suis confronté à un bug vraiment bizarre que je n'arrive pas à comprendre ni à résoudre sans passer par le reset du cache.

J'ai une liste de 4 objets très basiques que je requête en base (code / libellé, le code contient qu'une seule lettre). Je renvoie ensuite celui qui m'intéresse via une requête linq en singleOrDefault.
J'ai une erreur qui pète aléatoirement sur le singleOrDefault car il trouve plus d'un élément qui matche. En investigant plus en détail, je me suis rendu compte qu'aléatoirement, en retournant chercher ma liste de 4 objets en cache, les lettres du codes se dupliquaient sur certains d'eux :

J'ai 4 objets avec un code à "C", "R", "T" et "P", et un libellé bien distinct pour chaque, et aléatoirement le "T" se transforme en "R" (mais garde bien son libellé) et fait donc péter le Single fait derrière.
Le seul moyen de résoudre le pb actuellement, c'est de rafraichir la liste en BDD, là les lettres se remettent bien et l'erreur disparait, jusqu'à un nouvel appel qui aléatoirement remélange mes codes...

C'est tellement invraisemblable à mes yeux que j'espère que qqun aura une idée pour résoudre ce pb, sinon je mettrai un test d'unicité sur ma liste pour la rafraichir ou non, mais cette solution est moche et surtout j'ai peur que ce problème puisse arriver sur d'autres listes du cache.

Merci d'avance,

Guillaume
15/05/2018, 14h47
popo

C'est assez confus.
J'ai du relire plusieurs fois pour être certain de comprendre (et encore je ne suis pas sûr d'avoir compris).

Au début j'ai cru que la clé du dictionnaire était ce fameux code.
Et puis tu parles ensuite d'une liste de 4 objets dans le cache et j'en ai déduis que ton problème ne se situe pas sur le dictionnaire mais sur cette liste.
Du coup c'est perturbant de mentionner ce dictionnaire...

Je vais donc essayer de répondre au deux choses en ne sachant pas très bien ce qui te serviras.
1 - Si la clé du dictionnaire est le code, alors cette clé ne peux pas changer sinon ça planterai ailleurs et donc la piste à suivre c'est que ce n'est pas le T qui se transforme en R mais le libellé du T qui change.
2 - Si c'est dans la liste que ça se passe alors, tu dois avoir deux objets pointant sur la même adresse et change le contenu des deux en croyant n'en changer qu'un.

Sans code, il est difficile te dire où se situe ton erreur.
15/05/2018, 16h36
Maleantes

C'est vrai que c'était assez confus.

Pour clarifier le dictionnaire comporte une clé (string) et un jeu de données (objet ou liste d'objets)

Dans mon problème, c'est le jeu de données qui est en cause, donc pas de soucis du coté du dictionnaire.

Les données ne sont jamais mises à jour dans le cache. C'est un cache temporaire de 10min, qui ne fait que de la lecture de base (il lit, il stocke pour 10min, et lorsqu'on refait une requête sur le jeu de données et que la clé existe en cache, on va chercher les données sur le cache).

Le soucis, c'est que ce jeu de données change aléatoirement 1 fois sur 5, et pas n'importe comment, c'est toujours ma donnée au code "T" qui se transforme en code "R". Je pencherai donc plus sur un bug.

A noter qu'en debug, la donnée est déjà corrompue dans le cache, ça ne vient pas d'un traitement fait par la suite.

C'est vraiment très mystérieux...
15/05/2018, 19h48
DotNetMatt

Poste ton code. Les explications c'est bien beau mais ca ne mene jamais bien loin.
15/05/2018, 23h02
François DORIN
Un objet dans un cache, à moins qu'il soit immutable, peut être modifié. Il suffit qu'il y ait des références qui traine dans un coin.

Maintenant, comme précisé par DotNetMatt et popo, il nous faut du code pour comprendre le soucis. Au minimum :
- le code chargeant le cache ;
- le code raffraichissant le cache (si code différent) ;
- le code utilisant le cache.

Code:

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
74
75
76
77
78
79
80
81
82
83
84
85
86
87
Private Property Caches As New ConcurrentDictionary(Of CacheCategory, MemoryCache)
<ThreadStatic> Private SqlDataLayer As SQL_DataLayer
 
Private ReadOnly Property Policy As CacheItemPolicy
        Get
            Return New CacheItemPolicy() With {.AbsoluteExpiration = DateTimeOffset.UtcNow.AddMinutes(CInt(ConfigurationManager.AppSettings("TEMPS_CACHE")))}
        End Get
    End Property
 
    Private ReadOnly Property QuickPolicy As CacheItemPolicy
        Get
            Return New CacheItemPolicy() With {.AbsoluteExpiration = DateTimeOffset.UtcNow.AddSeconds(15)}
        End Get
    End Property
 
Private Sub AddToCache(categorie As CacheCategory, key As String, value As Object, Optional quickCache As Boolean = False)
        If Cache_Active Then
            Try
                If quickCache Then
                    Caches(categorie).Add(New CacheItem(key, value), QuickPolicy)
                Else
                    Caches(categorie).Add(New CacheItem(key, value), Policy)
                End If
            Catch ex As Exception
            End Try
       End If
End Sub
 
Private Function CacheContains(categorie As CacheCategory, key As String)
        If Cache_Active Then
            Try
                If Caches(categorie).Contains(key) Then
                    Return True
                End If
 
                Return False
            Catch ex As Exception
            End Try
        Else
            Return False
        End If
    End Function
 
Public Function Get_Dos_Collection(Of T)(Ctx As String, Optional Code As String = "") As IEnumerable(Of T)
        SqlDataLayer = New SQL_DataLayer
        Try
            Select Case GetType(T).Name.ToUpper
                Case "Code_Etat"
                    Dim key As String = "Get_Dos_Collection_code_Etat"
                    If CacheContains(CacheCategory.Dossier, key) Then
                        Return Caches(CacheCategory.Dossier)(key)
                    Else
                        Dim retour = SqlDataLayer.GetAll_Code_Etat(Ctx)
                        AddToCache(CacheCategory.Dossier, key, retour)
                        Return retour
                    End If
                Case ...........
            End Select
      Catch ex As Exception
      End Try
End Function
 
 
Public Function GetAll_Code_Etat(ByVal Contexte As String) As List(Of code_etat)
        Dim reader As DbDataReader = Nothing
        Dim Liste As New List(Of DOS_CODE_ETAT_DOSSIER)
 
        Try
            requete = "SELECT code, libelle, auto"
            requete &= " FROM code_etat"
            requete &= " ORDER BY libelle"
 
            reader = Ouverture_Reader()
 
            While reader.Read
                Dim UnObj = New code_etat
                UnObj.InitWithDataReader(reader, Contexte)
                Liste.Add(UnObj)
            End While
        Catch ex As Exception
        Finally
            FermetureReader(reader, True)
        End Try
 
        Return Liste
 
    End Function

D'avance désolé, je sais que c'est du VB mais c'est la même logique.
Pour expliquer un peu plus, le CacheCategory est un énumerable de plusieurs catégories d'objets et le SQL_DataLayer est la classe qui gère les accès en BDD, j'ai mis un exemple avec une fonction d'appel en base pour que vous ayiez un topo complet.
l'Ouverture_reader gère la commande et son execution en base et le InitWithDataReader sert juste à remplir les propriétés de l'objet.
Je n'ai pas mis la gestion d'erreurs pour ne pas alourdir.

Merci en tout cas,

Guillaume

J'ai déplacé le sujet dans le bon forum (VB.NET ;)).

Comme ça, je n'ai rien vu de choquant. Comment est appelée Get_Dos_Collection ? Il faudrait voir au niveau des utilisations si la liste n'est pas modifiée.

Sinon, j'ai juste vu un petit écueil qui peut arriver dans de rare condition (et donc difficilement reproductible).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Public Function Get_Dos_Collection(Of T)(Ctx As String, Optional Code As String = "") As IEnumerable(Of T)
        SqlDataLayer = New SQL_DataLayer
        Try
            Select Case GetType(T).Name.ToUpper
                Case "Code_Etat"
                    Dim key As String = "Get_Dos_Collection_code_Etat"
                    If CacheContains(CacheCategory.Dossier, key) Then
                        Return Caches(CacheCategory.Dossier)(key)
                    Else
                        Dim retour = SqlDataLayer.GetAll_Code_Etat(Ctx)
                        AddToCache(CacheCategory.Dossier, key, retour)
                        Return retour
                    End If
                Case ...........
            End Select
      Catch ex As Exception
      End Try
End Function

Le problème se situe lors de l'utilisation du cache. Entre la vérification de la présence de la clé, et le retour de la valeur contenue dans le cache, l'entrée peut devenir invalide, et donc le Return renvoyer null. Il faut juste le "bon timing"

Code:

1 2 3 4 Public Shared Function Load(ByVal ID As String) As CODE_ETAT Dim etat = CacheModule.Get_Dos_Collection(Of CODE_ETAT)("", True).SingleOrDefault(Function(e) e.DOS_CODE_ETAT = ID) Return If(etat, New CODE_ETAT) End Function
Pour clairement expliquer le problème qui m'arrive, j'ai 4 données renvoyées par la base :
1- Code "C", Libellé "CREATION"
2- "P", "PRISE DE CONTACT"
3- "R", "PRISE DE RENDEZ-VOUS"
4- "T", "MISSION CLOTUREE"

Lors de l'appel en base, aucun problème, mes 4 objets sont bien créés et les propriétés sont bonnes, puis celui-ci est mis en cache
Lors d'un nouvel appel, cette fois-ci en cache, aléatoirement, ma donnée a été corrompu, généralement sur mes cas relevés, c'est uniquement le "T" de "MISSION CLOTUREE" qui se change en "R".

Derrière ça génère donc un problème sur le singleOrDefault.

J'ai l'impression que c'est plus un bug du cache que de code, je me pose donc la question si y'a pas un bug de ce style qui a déjà été recensé, on bosse sur le framework 4.5.

Pour ta remarque, c'est vrai que dans des cas exceptionnels on peut retourner du nothing. Je vais plutôt séparer mon if else en deux if avec d'abord l'appel au cache, puis l'appel en BDD si le retour est nul. Merci

16/05/2018, 14h55
François DORIN

Citation:

Envoyé par Maleantes

J'ai l'impression que c'est plus un bug du cache que de code, je me pose donc la question si y'a pas un bug de ce style qui a déjà été recensé, on bosse sur le framework 4.5.

Par expérience, dans 99,9% des cas, ce genre de problème relève plus du code appelant que du framework .NET.

Une manière simple de s'en assurer, c'est de vérifier la valeur dans le cache juste après qu'il ait été initialisé. Normalement, il doit avoir la bonne valeur.

Je ne suis pas spécialiste VB.NET, mais je pense que l'erreur est dans la fonction appelée par la méthode
Mettre ensuite un point d'arrêt sur la ligne SingleOrDefault. Voir la valeur avant ET la valeur après l'exécution de la ligne. Si, et seulement si, dans le cas où la valeur change entre les deux, on pourra supposer un bug dans le framework. Il faudra aussi s'assurer que la méthode appelée par SingleOrDefault n'a pas d'effet de bord.

Sinon, le cas le plus problème, c'est que la valeur retournée est modifiée par le code (ce qui modifie le cache). Il faut donc voir comment est utilisée la valeur retournée ? Un "bon truc", s'il s'agit d'une propriété, mettre un point d'arrêt sur le setter.
16/05/2018, 15h57
Maleantes

Là où je penche sur un bug de framework, c'est que lorsque j'arrive dans mon module de cache en debug, avant même de retourner quoique ce soit, je vais voir mon dictionnaire de cache, et la donnée est déjà corrompue, sans qu'il n'y ait eu retouche du cache entre le moment d'enregistrement dans le cache et celui de l'appel.
A noter que lorsque je désactive le cache (appel constant en base), la donnée n'est jamais corrompue, alors qu'ils passent par les mêmes traitements.

Ma principale crainte, c'est de savoir si cette erreur peut se reproduire sur tous les objets car là ce serait plus problématique...
16/05/2018, 16h05
François DORIN

Comprenez bien que les objets que vous mettez en cache ont une vie. Même si vous n'avez pas encore utiliser le cache, vous avez bien utiliser des objets pour l'alimenter. Si ces objets sont modifiés, votre cache est modifié.

Le fait de ne pas se servir de cache résout le problème dans la mesure où à chaque fois, vous réutiliser des objets nouveaux.

Maintenant, sans connaissance des traitements que vous effectuez, impossible de savoir. Explorer donc déjà les pistes que je vous ai fourni. Pour ma part, je suis persuadé que vous avez un traitement qui modifie vos données sans que vous ne vous en rendiez compte.
16/05/2018, 17h21
Maleantes

C'est vrai que je ne voyais pas ça sous cet angle. Est-ce que cloner les objets avant de les renvoyer pourrait prévenir ce type d'erreurs ?

En gros, le principe serait de décorréler mes objets du cache des objets utilisés. En gros ils serviraient de "modèle" pour les objets utilisés
16/05/2018, 17h28
François DORIN

Citation:

Envoyé par Maleantes

C'est vrai que je ne voyais pas ça sous cet angle. Est-ce que cloner les objets avant de les renvoyer pourrait prévenir ce type d'erreurs ?

Oui, ça devrait le faire.
Pour ma part, ce que je fais c'est que je rend ces objets immutables, de sorte que je suis sur de ne pas pouvoir les modifier après coup. Sinon, il y a aussi la possibilité d'utiliser des Struct au lieu d'une Class
16/05/2018, 17h36
Maleantes

Le cache a été rajouté sur une grosse structure fonctionnelle donc le but c'est d'essayer de limiter au maximum les changements de l'existant.

Sinon, je pensais à autre chose, ce serait de sérialiser les données à leur sauvegarde en cache, et de les déserialiser à leur sortie, ça éviterait tout stockage d'objet.

Qu'en pensez vous ?

En tout cas, vraiment merci pour votre aide :)
16/05/2018, 17h42
François DORIN

Citation:

Envoyé par Maleantes

Sinon, je pensais à autre chose, ce serait de sérialiser les données à leur sauvegarde en cache, et de les déserialiser à leur sortie, ça éviterait tout stockage d'objet.

Oui, ça devrait marcher. Serialiser/déserialiser est un moyen de cloner les objets