Discussion :

[richard_sraing]

Bonjour à tous,

Me revoilà avec une question qui, à mon avis, n'est pas simple à formuler.

Le contexte :

Je développe actuellement une application client/serveur multithread. Pour le stockage de mes données, j'utilise une base de données MySQL.
Le serveur est structuré de la manière suivante dans l'état actuel de la chose :

J'ai dès lors un soucis avec l'architecture actuelle. Il m'est impossible de retourner le résultat de mon thread DB vers le bon thread correspondant dans le pool de thread.
J'ai donc pensé changer l'architecture pour que mon pool de thread réalise lui même les opérations d'accès à la base de données au travers d'un objet DbAccess (créé par mes soins et chargé de parser les données, créer les requêtes, ...).

Or, je me pose la question de savoir dans quelle mesure il est sûr de faire accéder chaque thread de mon pool à la base de données.

J'ai posé une question sur une autre partie du forum pour voir si il est préférable de recréer une socket à chaque nouvelle requête du client, ou alors de maintenir la connexion, et l'on me conseille d'utiliser les tokens (pas la moindre idée de comment faire).

Voilà, en espérant être clair au niveau de ma question, j'attends vos avis et conseil afin de me permettre d'avancer au mieux dans le développement de cette application.

[Chatanga]

Tout d’abord, il est casse-gueule de bâtir l’architecture d’une solution à un problème qu’on ne connaît pas. Il n’y a pas de meilleur manière de faire en informatique, c’est d’ailleurs la raison qui peut justifier de ne pas utiliser des solutions clef en main inadaptée (p. ex. utiliser Glassfish pour un FPS en ligne).

Ceci étant, voici déjà quelques remarques :

Tu semble considérer les pipes comme unique solution à la communication entre threads. Si tu créais des processus plutôt que des threads, çà ne serait pas déconnant. Pour des threads qui partagent le même espace mémoire, ça n’a cependant pas beaucoup de sens de s’imposer une telle contrainte.

Donner accès à ta base de données à chaque thread de ton pool ne pose pas de problème de sécurité, sauf synchronisation maladroite, mais de concurrence. Est-ce que tu as vraiment besoin d’accès synchrone à ta base ? Ça peut simplifier les choses d’être synchrone et ne pas poser de problème si les requêtes sont légères. Ça peut aussi entraîner des congestions inacceptables pour de nombreux clients et totalement inutiles si, par exemple, leurs traitements sont décorrelés. Là encore, pas de solution unique.

Pour ce qui de la création de socket pour chaque échange entre un client et le serveur, ça ne change rien au problème d’accès à la base de données. Tu auras de toute manière une notion de session persistante (que tu lieras justement au socket se créant via ce token).

[richard_sraing]

Mouais, voici plusieurs remarques très pertinente, et je vais tenter de justifier mes choix.

Tu parles de solution clefs en main. Dans mon cas, il s'agit de l'opposé complet. Les seuls choses clefs en mains utilisées sont les classes de gestion pour l'accès à la BD. Pour tout le reste, j'utilise mes 10 doigts et le peu de cerveau qu'il me reste pour avancer.

Tu parles de processus plutôt que de threads. Le choix c'est porté sur le thread, justement, car il est plus simple de faire communiquer des threads, et surtout moins gourmands en temps machines (à ma connaissance en tout cas) que de faire communiquer des processus.
Pour la communication interthread, le tout est géré en mémoire. A l'inverse, la communication inter process, se fait par le biais de "fichiers", qui est, toujours à ma connaissance, plus lourde.

Pour l'accès à la BD, existe-t-il une bonne pratique justement, pour ces problèmes de concurrences ? Etant donné que je souhaites attribuer à chaque thread un objet qui lui sera propre pour la communication avec la BD, est-il possible de mettre en place un mutex || sémaphore global à tout les objets d'accès BD, permettant de limiter, voire empêcher les accès concurrents sur la BD (par exemple, bloquer les accès à la BD lors d'un update / insert / delete).

Pour la création de socket, c'était plutôt dans l'optique de ne pas saturer le serveur avec des connexions inactives (collègues qui lance l'appli et part prendre un café).

[Chatanga]

Je reformule :

Si tu créais des processus plutôt que des threads, ça ne serait pas déconnant (que tu semble considérer les pipes comme unique solution à la communication entre threads).

A l'inverse, la communication inter process, se fait par le biais de "fichiers", qui est, toujours à ma connaissance, plus lourde.

Oui, donc pourquoi faire figurer des pipes (pipe = fichier en gros = communication inter-processus) sur ton schéma ?

Pour l'accès à la BD, existe-t-il une bonne pratique justement, pour ces problèmes de concurrences ? Etant donné que je souhaites attribuer à chaque thread un objet qui lui sera propre pour la communication avec la BD, est-il possible de mettre en place un mutex || sémaphore global à tout les objets d'accès BD, permettant de limiter, voire empêcher les accès concurrents sur la BD (par exemple, bloquer les accès à la BD lors d'un update / insert / delete).

La bonne pratique justement pour ces problèmes de concurence est d’utiliser directement une base de données classique (principe ACID). Vu tes besoins, ou plutôt leur absence, ça répond à ton problème. J’imagine que tu ne prévoyais pas de développer ta propre base, non ?

[richard_sraing]

Bonjour,

Alors, je pense que j'utilise mal le terme pipe. Pour moi, un pipe est un tube de communication de manière générique. Dans mon cas, il s'agit simplement d'un objet contenant une LinkedList avec deux méthodes (add et get) et un wait sur la list (donc rien à voir avec les fichiers en fait).

Concernant la base de données, effectivement, je ne prévois pas d'en développer une (aux vues des contraintes qui existe sur un système de SGBD, je pense qu'il s'agirait d'un projet d'une vie ;-)).

La bonne pratique justement pour ces problèmes de concurence est d’utiliser directement une base de données classique (principe ACID).

Après brève recherche du principe ACID, beaucoup de souvenir d'école me revienne (comme je détestais le SGBD à l'époque ).
Par base de données classique, si je comprends bien, on parle de MySQL, Oracle, et tous les autres ?
Mais pour y accéder, dois-je prendre des précautions lorsque mes threads accéderont à la BD ?

[sinok]

T'es tu penché sur les notions de Future présents en java depuis sa version 1.5?

http://java.dzone.com/articles/javautilconcurrentfuture
http://www.vogella.com/articles/Java...e.html#futures