Paramètre système USE_ORACLE_SEQUENCE et duplicate row_id

Support
1

Bonjour,

Mon appli est en version 3.0 et utiliser une base MySQL.
Je rencontre un bug lors de la création d’un objet par le code java.

com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry ‘15683313’ for key ‘PRIMARY’

Mon code de création :

reservationMT.setRowId(ObjectField.DEFAULT_ROW_ID);
reservationMT.setFieldValue(“ormtReservationId”, res.get(0)[0]);
reservationMT.setFieldValue(“ormtRessourceId”, getRowId());
reservationMT.setFieldValue(“ormtType”, OsgoResaMoyenTest.TYPE_MT_MOBILE);
reservationMT.setFieldValue(“ormtStatutResa”, OsgoResaMoyenTest.STATUT_POSEE);
reservationMT.create();

Je pense que le système utilise une séquence oracle qui devient désynchronisée au bout d’un certains temps et donc bloque la création.

Est-il possible de changer la valeur du paramètre système USE_ORACLE_SEQUENCE de “yes” à “no” ?
Si oui, y a-t-il un impact sur la base de données?

Merci d’avance pour votre réponse.

2

Le parametre USE_ORACLE_SEQUENCE ne concerne que les bases Oracle.

Sur une base MySQL il n’y a pas de séquence au sens Oracle mais, en théorie, il ne devrait pas pouvoir y avoir de pb de duplicate key sur le row ID à moins d’être dans un cas particulier d’usage non prévu.

Pouvez vous préciser dans quel contexte vous avez ces erreurs ?
Merci

3

Après déploiement de code et vidage de cache, le code de création mentionné dans le premier post fonctionne comme attendu.
(L’objet est créé dans le postCreate d’un autre objet)
Le lendemain, la création ne fonctionne plus à cause du problème de duplicate key.

Ce comportement s’est reproduit plusieurs fois.

Lundi matin, détection du bug.
Lundi soir, j’ajoute des logs sans toucher au code de création pour essayer d’identifier le bug. Je déploie le code et la création fonctionne.

Mardi matin, le bug revient.
Mardi soir, je change le code de création et j’ajoute

reservationMT.setRowId(ObjectField.DEFAULT_ROW_ID);

et

reservationMT.create(); // à la place d’un .save();

Après déploiement, la création fonctionne.

Mercredi, problème de création revient avec toujours duplicate row_id.

4

OK je note que votre problème se produit dans le cas d’une création par code d’un objet B dans le postCreate d’un objet A.

Et je comprends que visiblement le pb ne se produit pas systématiquement et que ce n’est pas directement lié à la manière dont le code est écrit.

Est-ce que, aux moments où le pb s’est manifesté, il y avait une forte charge sur cet objet (nombreuses sessions utilisateur et/ou traitements d’imports en masse, …) ?

Indépendamment de cela pourriez vous nous indiquer si votre version 3.0 est bien à à jour de ses patches de maintenance. Pour cela pouvez vous nous envoyer le résultat d’un appel sur /health de votre instance ?
Merci

5

Voici le health de l’instance

[Platform]
Status=OK
Version=3.0.MAINTENANCE-28
Builton=2016-03-10
Encoding=ISO-8859-1
SystemDate=2018-01-15 09:58:44

[Application]
ApplicationVersion=version 4.9.5
ContextPath=/pepsmoa
ContextURL=http://10.111.184.73:8080/pepsmoa
EnabledUsers=109
TotalUsers=209

[OS]
Name=Windows Server 2008 R2
Architecture=amd64
Version=6.1

[Disk]
DiskFree=116602
DiskUsable=116602
DiskTotal=295625

[JavaVM]
Version=1.7.0_45
Vendor=Oracle Corporation
VMname=Java HotSpot™ 64-Bit Server VM
VMversion=24.45-b08
HeapFree=224717
HeapSize=409600
HeapMaxSize=932352
TotalFreeSize=747469

[Cache]
GrantCache=22/1000
ObjectCache=175/10000
ProcessCache=0/10000

[Database]
Vendor=1
ProductName=MySQL
DriverName=MySQL-AB JDBC Driver
DriverVersion=mysql-connector-java-5.1.18 ( Revision: tonci.grgin@oracle.com-20110930151701-jfj14ddfq48ifkfq )
DBDate=2018-01-15 09:58:44
DBDateoffset=0 sec

[Healthcheck]
Date=2018-01-15 09:58:44
ElapsedTime=93ms

Je ne sais pas il y avait combien d’utilisateurs connectés quand le problème s’est manifesté, mais il y a en général pas plus de 5 personnes connectées en même temps.

Pas de d’import en masse non plus.

6

Vous utilisez visiblement la release de maintenance 3.0 M28 datée du 10/03/2016

La release actuelle sur la branche 3.0 est la M35 (avec dernier commit au 24/11/2017

Entre votre release et ce dernier commit il y a eu pas moins de 308 commits (!) sur cette branche.

Et en faisant une comparaison entre ce dernier commit et votre release on trouve de très nombreuses différences notables, notamment sur le “coeur” du moteur Simplicité (en particulier sur l’object loader et l’object manager, ce dernier s’occupant, entre autre, de la gestion de la création row IDs).

Dans ce contexte nous vous suggérons donc de commencer par upgrader. Si le problème que vous remontez persiste nous investiguerons plus avant.

En attendant nous pouvons vous mettre à disposition une instance 3.0 (sur MySQL) à jour afin que vous y testiez votre paramétrage.

7

PS: Je précise en outre que la date officielle de fin de maintenance long terme sur la branche 3.0 est février 2018.