Architecture d'un client lourd (Swing) avec Hibernate

Bonjour,
Je collabore depuis peu à un projet au travail dans lequel quelque chose me chiffonne.

Il s'agit d'une appli Swing faisant des accès bdd vers un serveur distant, au moyen tantôt d'hibernate, tantôt de jdbc direct.

Le problème est que les requêtes complexes faites avec Hibernate sont extrêmement peu performantes, et sont donc remplacées par des requêtes SQL.

Je n'ai pas regardé en profondeur, mais il apparait clairement que chaque client Swing utilise la session Hibernate sur sa propre JVM.

Hors pour utiliser les capacités de cache d'hibernate, il apparait logique de mettre hibernate côté serveur, et de faire des appels RMI (ou http) entre le client et le serveur.
Tel que fait actuellement, si deux personnes utilisent l'application en même temps, ils ne peuvent partager le même cache. Pire, il y aurait des incohérence sur le client avec des requêtes pure jdbc si Hibernate n'a pas flush correctement (je soupçonne en fait le cache d'être tout simplement disabled).

Est-ce que mon raisonnement semble logique ? Est-ce que l'on a bien là un anti-pattern ?

Salut,

Si j'ai bien compris, les applis Swing client font appel directement au serveur de base de données, il n'y a pas d'application au niveau du serveur qui joue l'interface entre les clients et le serveur de base de donnée, j'avoue que je n'ai pas encore eu l'occasion de faire de l'hibernate, mais si c'est bien le cas, je crois qu'utiliser Hibernate ou du pure JDBC ne changera rien, puisque chaque client à sa propre connexion directe à la base de donnée.

Citation:

---

nicorama dit:
Hors pour utiliser les capacités de cache d'hibernate, il apparait logique de mettre hibernate côté serveur, et de faire des appels RMI (ou http) entre le client et le serveur.

---

C'est exactement ça, quand tu as parlé de RMI et http, il devrait y avoir un serveur d'application au niveau du serveur et qui, lui seul devrait accéder à la base de donnée, c'est lui qui devrait implémenter de l'hibernate ou du JDBC, tous les clients ne se connecteraient que via ce serveur d'application.

Quand je relis ce que j'ai écrit, je m'aperçois de ne t'avoir rien dit de plus :aie:, au minimum, ça up ton problème, en espérant que quelqu'un y voit plus clair.

Salut ;-)
Supposant que nous sommes entrain d'utiliser un client lourd swing communiquant avec un serveur basé Spring Framwork via Spring RMI, qui se connecte avec une petite base de données Derby via iBatis.

Pourriez-vous me donner quelques idées sur les accès concurrents, ou bien sur les transactions, et sans oublier que tous les beans implémentes l'interface Serializable, ainsi que toutes les méthodes DAO sont synchronized.

Je veux dire que notre serveur sera accédé par plusieurs clients et en réseaux !


Merci d'avance.

Cordialement !

Citation:

---

Envoyé par nicorama

Bonjour,
Hors pour utiliser les capacités de cache d'hibernate, il apparait logique de mettre hibernate côté serveur, et de faire des appels RMI (ou http) entre le client et le serveur.

---

Bonjour, sauf si vous configuré un cache de second niveau (qui souvent n'aura rien de magique), le cache hibernate est ce qu'on appelle le cache de premier niveau qui correspond à la session hibernate.
Comme les différents clients n'utilisent pas la même session Hibernate, déporter hibernate coté serveur ne changera rien à vos performances.

Avant de commencer à regarder ce genrer de chose, a votre place je regarderai a quoi ressemble les requête SQL générées par hibernate (via un showSql=true). Si les requêtes sont trop complexes ou trop nombreuses, cela cache une mauvaise utilisation d'hibernate et le mettre coté serveur ne changera rien.