Discussion :

[Aéris22]

Bonjour à tous

J'ai actuellement un problème à résoudre dont les solutions que j'ai pu trouver ne me conviennent pas parfaitement.

Dans application sur laquelle je travaille actuellement, il y a 2 composants principaux:
— Une partie interface, accessible par les différents utilisateurs
— Une partie traitement, accessible uniquement par le système (une API interne en quelque sorte)

La partie traitement est lancée dans un thread séparé, en attente des ordres en provenance de la partie utilisateur. D'un point de vue utilisateur, c'est une grande FIFO avec priorité.
La partie utilisateur peut aussi bien être un site web qu'un client léger.

Le soucis que j'ai actuellement est sur la transmission de la session (ouverte en espace utilisateur) à l'espace système.
En gros, 90% de l'application pourrait se résumer à:
— L'utilisateur remonte des données de la bdd
— L'utilisateur effectue des modifications sur les données
— L'utilisateur soumet une demande à la partie système
— Le système agit SUR LES OBJETS UTILISATEURS après contrôle
— L'utilisateur récupère le résultat et l'affiche

Le soucis est sur la transmission de la session ouverte entre la partie utilisateur et la partie système.
L'utilisateur n'ayant pas connaissance des modifications faites par le système, ce n'est pas lui qui peut les persister en base.
Mais le système étant dans un autre thread, toute stratégie de « getCurrentSession » est vouée à l'échec, les objets persistants étant déjà raccrochés à la session utilisateur qui ne peut pas être récupérée côté système.

J'ai trouvé 2 solutions à mon problème, mais aucune n'est correcte à mon goût:
— À chaque retour du système, l'utilisateur n'ayant aucune idée de quelles données ont été modifiées doit faire un update en cascade sur tous ses objets remontés de la bdd afin de les persister
— À chaque fois qu'un des composants doit modifier ou accéder (lazy…) aux données, il doit s'assurer de reconnecter l'objet à la session courante. Dès l'entrée dans le système, on lock tout à la session système, à la sortie on relock tout à la session utilisateur, à l'update/save/delete aussi, etc…

Dans les 2 cas, l'abstraction de la bdd est très faible (le développeur passe plus de temps à gérer la session qu'à développer son code métier), peut mener à des problèmes de performance (updates en cascade inutiles) ou à des erreurs difficilement gérables (lazy loading en particulier).

Est-ce que vous auriez des idées de comment gérer ce cas de manière propre, c'est-à-dire que l'utilisateur n'ait pas (trop) à se soucier de la gestion des modifications du système sans pour autant nécessiter de trimballer la session utilisateur au 4 coins du système?

Merci d'avance pour vos idées !

[OButterlin]

Je pense qu'il y a un problème dans l'architecture de ton application.
Si le client n'a pas la "maîtrise" des données de la base de données, il ne devrait pas utiliser d'accès à celle-ci.
Il serait préférable de passer par une couche de communication (à base de socket ou autre).
Ta partie "serveur" s'occupe de traiter la demande de "lecture" du client et fournit en retour le graphe d'objets (DTO ou autre classe serializable).
Pour la modification, le client envoie le graphe au serveur et c'est lui qui s'occupe de mettre à jour la DB.

[Aéris22]

En fait si, il a la maîtrise.
Théoriquement parlant, je pourrais exécuter tout le code du moteur dans la partie cliente comme un simple accès à la couche service.

Le moteur est en fait uniquement là pour synchroniser et régulariser temporellement les demandes.
En gros, si je connais les X clients connectés avec les dates précises de leurs demandes, je dois garantir l'ordre d'exécution en bdd, fonction uniquement de ces paramètres, chaque demande pouvant rendre illégale la demande d'un autre client.
Sachant en plus que le moteur agit aussi comme un «client» en injectant des demandes régulièrement (tâches d'arrière plan).

Et les clients ont besoin d'avoir accès aux données, ne serait-ce que pour les afficher. Les demandes au serveur ne sont que facultatives, en fonction de ce sur quoi agit l'utilisateur humain. Les données affichées doivent aussi tenir compte de si la demande potentiellement effectuée s'est bien passée ou non (potentiellement elle sera refusée par le serveur car incompatible avec une autre demande d'un autre client)