HOAB

History of a bug

synchronisation via SELECT FOR UPDATE et données non mises à jour !

Rédigé par gorki Aucun commentaire

Le problème :

Un problème tout simple ou presque :)

Deux threads qui discutent avec la base de données, synchronisés par un "SELECT ... FOR UPDATE" sur le même objet.

Le deuxième thread n'a pas toujours le résultat du travail du premier thread !

Solution :

Alors j'écarte toutes les hypothèses qui m'ont été faites :

  • une seule transaction par thread de la prise de lock au commit
  • transaction en REQUIRED_NEW
  • le lock via le SELECT FOR UPDATE est la première instruction des threads
  • pas d'instruction DDL pendant les threads
  • le SELECT FOR UPDATE fonctionne correctement

La réponse : Mysql utilise par défaut le mode d'isolation READ REPEATABLE alors que la plupart des autres bases utilisent READ COMMITED.

Comme j'imagine que ce n'est pas évident, quelques explications :

Thread n°1 Thread n°2 Mysql Mode : REPEATABLE READ Mysql Mode : READ COMMITED
SELECT tableLock FOR UPDATE WHERE id = 1      
UPDATE user.status = 4      
start thread n°2      
  SELECT tableLock FOR UPDATE WHERE id = 1 Snapshot de la base pour avoir des données constantes pendant la transaction Pas de snapshot, ce sont les dernières données en base
Commit      
  Obtention du lock APRES le commit    
  select user.status status est null / non mis à jour status = 4 !

Remarques :

  • Le thread n°2 déclenché par le thread n°1 se met en attente du lock. En faisant un SELECT !. C'est là le problème. Le mode REPEATABLE READ fait un snapshot valable sur la base entière au premier select.
  • ce point (snapshot sur la base entière) n'est pas très explicite dans les documentations

Solutions :

  • passer MYSQL en mode READ COMMITED (un peu performant en plus...)
  • mettre les mises à jour des données autres dans des sous-transactions
  • envisager un autre mode de synchronisation hors transaction (cache distribué...)

 

RestAssured Junit et tests Session

Rédigé par gorki Aucun commentaire

Le problème :

RestAssured est un framework de tests pour les services Rest avec un langage assez simple.

Le seul problème est qu'il demande à ce qu'un serveur soit démarré, ce qui est toujours un peu lent pour les tests unitaires.

Heureusement, est inclu RestAssuredMockMvc qui permet de mocker le serveur, faire "comme si" on avait un serveur, très bien !

Problème :

  • Dans un de mes tests j'utilisent des informations stockées en session

Autant RestAssured a prévu le coup et a des méthodes pour ça (cf SessionFilter) côté client, autant la partie RestassuredMockMvc n'a rien de tout ça dans la partie serveur simulé.

Solution :

J'ai pas mal tatonné/recherché, mais finalement une solution assez simple et non intrusive :

// Création de la requête de test avec serveur simulé (le given() de RestassuredMockMvc)
MockMvcRequestSpecification request = given().standaloneSetup(controller);

// Création d'un session vide
final MockHttpSession session = new MockHttpSession();

// On ajoute un interceptor pour indiquer lors de la construction de la requête d'utiliser notre session
request.interceptor(new MockHttpServletRequestBuilderInterceptor() {
            @Override
            public void intercept(MockHttpServletRequestBuilder requestBuilder) {
                requestBuilder.session(session);
            }
});

// on peut ensuite enchainer les appels, la session sera la même

request.queryParam(...).when(...)...

request.queryParam(...).when(...)...

Donc côté serveur simulé, on intercepte le constructeur pour lui donner une session vide (mais non null). On pourrait imaginer un système plus complexe pour gérer le fait qu'au premier appel la session devrait être null, mais on va s'arrêter là pour l'instant.

 

 

Fil RSS des articles