Une alternative à Hibernate ou TopLink? [fermé]

Question

Existe-t-il une alternative viable à Hibernate? De préférence, quelque chose qui ne se base pas sur JPA.

Notre problème est que nous construisons un système RIA avec état complexe (comme dans de nombreux objets qui se réfèrent). Il semble qu'Hibernate soit conçu pour être utilisé principalement dans des applications ponctuelles - JSF et autres.

Le problème est principalement celui du chargement paresseux. Puisqu'il peut y avoir plusieurs requêtes HTTP entre l'initialisation et le chargement de collections différées, une session par transaction est hors de question. Une session de longue durée (une par application) ne fonctionne pas bien non plus, car une fois qu'une transaction rencontre un problème et lève une exception, toute la session est invalidée, ainsi les objets chargés paresseux se cassent. Ensuite, il y a toutes sortes de choses qui ne fonctionnent tout simplement pas pour nous (comme les données implicites qui persistent des données en dehors d'une transaction initialisée).

Mes pauvres explications, mis à part le fait qu'Hibernate fait de la magie que nous n'aimons pas. Il semble que TopLink ne soit pas meilleur, il est également écrit sur EJB.

Ainsi, nous aurions le plus besoin d’une couche de persistance sans état (ou même d’une couche d’abstraction de base de données orientée objet suffisamment brillante).

Avez-vous des idées ou est-ce que je demande quelque chose qui n'existe pas?

Modifier: Je m'excuse pour la terminologie ambiguë que je vous remercie, et merci à tous pour vos corrections et vos réponses judicieuses. Ceux qui m'ont corrigé, vous avez tous raison, je parlais de JPA, pas d'EJB.

Answer 1

Comme mentionné, JPA < > EJB, ils ne sont même pas liés. EJB 3 utilise JPA, mais c’est à peu près tout. Nous avons un tas de choses utilisant JPA qui ne sont même pas près d’exécuter EJB.

Votre problème n'est pas la technologie, c'est votre conception.

Ou, devrais-je dire, votre conception n’est pas un ajustement facile sur pratiquement TOUT cadre moderne.

Plus précisément, vous essayez de maintenir les transactions actives sur plusieurs requêtes HTTP.

Naturellement, la plupart des idiomes courants sont que chaque demande est en soi une ou plusieurs transactions, plutôt que chaque demande étant une partie d'une transaction plus importante.

Il existe également une confusion évidente lorsque vous utilisez le terme & "; apatride &"; et " transaction " dans la même discussion, car les transactions sont intrinsèquement avec état.

Votre gros problème consiste simplement à gérer vos transactions manuellement.

Si votre transaction se produit sur plusieurs requêtes HTTP ET que ces requêtes HTTP s'exécutent & "; très rapidement &" ;, l'une après l'autre, vous ne devriez pas vraiment avoir de problème. , enregistrez que vous devrez vous assurer que vos requêtes HTTP utilisent la même connexion à la base de données afin de tirer parti de la fonctionnalité de transaction de bases de données.

En d’autres termes, vous obtenez une connexion à la base de données, vous la renseignez dans la session et assurez-vous que, pendant la durée de la transaction, toutes vos requêtes HTTP passent non seulement par la même session, mais également par la même session. de telle sorte que la connexion réelle soit toujours valide. Plus précisément, je ne pense pas qu'il existe une connexion JDBC prête à l'emploi qui survivra réellement au basculement ou à l'équilibrage de charge d'un ordinateur à un autre.

Donc, si vous voulez utiliser des transactions de base de données, vous devez vous assurer que vous utilisez la même connexion à la base de données.

Maintenant, si votre transaction de longue durée comporte & "; interactions d'utilisateur &"; Dans ce cadre, c’est-à-dire que vous démarrez la transaction de base de données et attendez que l’utilisateur & "fasse quelque chose &"; puis, tout simplement, cette conception est totalement fausse. Vous ne voulez PAS faire cela, car les transactions de longue durée, en particulier dans les environnements interactifs, sont tout simplement mauvaises. Comme & Quot; Traverser les ruisseaux & Quot; Mal. Ne le fais pas. Les transactions par lots sont différentes, mais les transactions interactives de longue durée sont mauvaises.

Vous souhaitez que vos transactions interactives soient aussi courtes que pratiques.

Maintenant, si vous ne pouvez PAS vous assurer que vous pourrez utiliser la même connexion à une base de données pour votre transaction, alors, félicitations, vous devez implémenter vos propres transactions. Cela signifie que vous concevez votre système et vos flux de données comme si vous n'aviez aucune capacité transactionnelle sur le back-end.

Cela signifie essentiellement que vous devrez créer votre propre mécanisme pour & "commit &"; vos données.

Un bon moyen de procéder consiste à créer progressivement vos données dans une seule & "; transaction &"; document, puis transférez-le dans un " save " routine qui fait beaucoup du vrai travail. Par exemple, vous pouvez stocker une ligne dans la base de données et la marquer comme & "Non sauvé &"; Vous le faites avec toutes vos lignes et appelez enfin une routine qui parcourt toutes les données que vous venez de stocker, et marquez le tout comme & "Enregistré &"; dans un processus de mini-lot de transaction unique.

En attendant, tous vos autres SQL " ignorent " données qui ne sont pas " sauvegardées " ;. Ajoutez des horodatages et effectuez un processus de nettoyage (si vous voulez vraiment vous déranger - il est peut-être moins coûteux de simplement laisser des lignes mortes dans la base de données, cela dépend du volume), ces morts & "Non sauvés quot; les lignes, car il s'agit de & "; non commentées &"; transactions.

Ce n'est pas aussi grave que ça en a l'air. Si vous voulez vraiment un environnement sans état, comme cela me semble, alors vous devrez faire quelque chose comme ça.

Attention, dans tout cela, la technologie de persistance n’a vraiment rien à voir avec it. Le problème est de savoir comment vous utilisez vos transactions, plutôt que la technologie.

Answer 2

Si vous recherchez un autre fournisseur JPA (Hibernate en est un), consultez EclipseLink . Il est bien plus complet que l'implémentation de référence de TopLink Essentials dans JPA 1.0. En fait, EclipseLink sera l’implémentation de référence JPA 2.0 fournie avec Glassfish V3 Final.

JPA est bon car vous pouvez l'utiliser à l'intérieur et à l'extérieur d'un conteneur. J'ai écrit aux clients Swing qui utilisent JPA à bon escient. Il n’a pas les mêmes stigmates et bagages XML que l’EJB 2.0 / 2.1.

Si vous recherchez une solution encore plus légère, ne cherchez pas plus loin que ibatis , ce que j’envisage. être ma technologie de persistance de choix pour la plate-forme Java. Il est léger, repose sur le langage SQL (le temps passé par les utilisateurs d’ORM à essayer de leur permettre de produire un bon code SQL est étonnant) et effectue 90 à 95% de ce que JPA effectue (y compris le chargement paresseux d’entités liées si vous le souhaitez).

Juste pour corriger quelques points:

• JPA est la couche de péristence des EJB, non construite sur les EJB;
• Tout bon fournisseur JPA a beaucoup à faire en cache et il peut être difficile de tout comprendre (ce serait un bon exemple de & "Pourquoi la simplicité est-elle si complexe? &";) . Sauf si vous faites quelque chose que vous n'avez pas indiqué, les exceptions ne devraient pas être un problème pour vos objets gérés. Les exceptions d'exécution annulent généralement les transactions (si vous utilisez la gestion des transactions de Spring et qui ne le fait pas?). Le fournisseur conservera des copies en cache des objets chargés ou persistants. Cela peut être problématique si vous souhaitez mettre à jour en dehors du gestionnaire d'entités (nécessitant un vidage de cache explicite ou l'utilisation de EntityManager.refresh()).

Answer 3

Je pense que vous devriez jeter un coup d'œil à apache cayenne , qui est une très bonne alternative à & "grand &" cadres. Avec son modéliste décent, la courbe d’apprentissage est raccourcie par une bonne documentation.

Answer 4

J'ai consulté SimpleORM l'année dernière et j'ai été très impressionné par son design léger et non magique. . Maintenant, il semble y avoir une version 3, mais je n'ai aucune expérience avec celle-là.

Answer 5

ORM Ebean ( http://www.avaje.org )

C'est un ORM plus simple et intuitif à utiliser.

• Utilise les annotations JPA pour la cartographie (@Entity, @OneToMany, etc.)
• API sans session - Pas de session Hibernate ou de gestionnaire d'entité JPA
• Le chargement paresseux ne fonctionne que
• Prise en charge partielle des objets pour de meilleures performances
• Réglage automatique de la requête via & "Extraction automatique &";
• Intégration de Spring
• Prise en charge des requêtes volumineuses
• Excellent support pour le traitement par lots
• Récupération en arrière-plan
• Génération DDL
• Vous pouvez utiliser du SQL brut si vous voulez (aussi bon que Ibatis)

• Licence LGPL

• Rob.

Answer 6

BEA Kodo (anciennement Solarmetric Kodo) est une autre alternative. Il prend en charge JPA, JDO et EJ3. Il est hautement configurable et peut prendre en charge les prélèvements agressifs, le détachement / la fixation d'objets, etc.

Cependant, d'après ce que vous avez décrit, Toplink devrait pouvoir gérer vos problèmes. La plupart du temps, il semble nécessaire de pouvoir attacher / détacher des objets de la couche de persistance au début et à la fin des demandes.

Answer 7

Pour rappel, la conception de l'OP est son plus gros problème: étaler les transactions sur plusieurs demandes d'utilisateurs signifie que vous pouvez avoir autant de transactions ouvertes à un moment donné que des utilisateurs sont connectés à votre application - une transaction garde la connexion occupée jusqu'à ce que il est engagé / annulé. Avec des milliers d'utilisateurs connectés simultanément, cela peut potentiellement signifier des milliers de connexions. La plupart des bases de données ne supportent pas cela.

Answer 8

Ni Hibernate ni Toplink (EclipseLink) ne reposent sur EJB, ce sont tous deux des cadres de persistance (ORM) POJO.

Je suis d’accord avec la réponse précédente: iBatis est une bonne alternative aux frameworks ORM: un contrôle total sur SQL, avec un bon mécanisme de mise en cache.

Answer 9

Une autre option est le couple, je ne dis pas que c’est mieux que l’une des options mentionnées ci-dessus, mais simplement que c’est une autre option à examiner. Il commence à être très vieux maintenant mais peut répondre à certaines de vos exigences.

Torque

Answer 10

Lorsque je cherchais moi-même un remplaçant pour Hibernate, je suis tombé sur DataNucleus Access Platform , qui est un ORM sous licence Apache2. Il ne s’agit pas uniquement d’ORM, car il assure la persistance et la récupération des données également dans d’autres sources de données que le SGBDR, telles que LDAP, DB4O et XML. Je n'ai aucune expérience d'utilisation, mais cela semble intéressant.

Answer 11

Envisagez de rompre complètement votre paradigme avec quelque chose comme tox . Si vous avez besoin de classes Java, vous pouvez charger le résultat XML dans JDOM .