Service de tentative d'accès
La tentative d'accès est un service d'exécution de serveur d'applications qui vous permet de gérer précisément la persistance d'une application.
Le service de tentative d'accès définit un ensemble d'annotation déclaratives utilisées par le conteneur d'EJB (Enterprise JavaBeans) et ses agents afin d'optimiser les performances pour l'accès au bean entity. Ces annotations sont organisées en ensembles appelés règles de tentative d'accès.
Les règles de tentative d'accès contiennent un ensemble d'annotations considérées comme indications par le conteneur d'EJB et ses agents. La plupart des règles de tentative d'accès sont des indications représentant des abstractions de haut niveau pouvant être mappées vers un gestionnaire de ressources spécifique. Le mécanisme de persistance d'EJB est chargé de vérifier le contrôle de connexion, la gestion de la cache et des connexions lors de la transmission des détails de persistance. Le gestionnaire de persistance d'EJB peut utiliser les instructions de tentative d'accès pour prendre de meilleures décision de performances lors de l'exécution de sa tâche assignée. Un nombre inférieur de tentatives d'accès qui sont des indications pour le conteneur d'EJB influe sur la gestion des collections d'EJB.
En général, les tentatives d'accès des applications sont configurées au niveau bean. Vous pouvez également appliquer des règles de tentative d'accès à des beans au sein de profils d'applications. Par conséquent, vous pouvez configurer des beans avec plusieurs règles de tentative d'accès opposées. La documentation relative au profilage d'application explique de manière plus détaillée comment configurer une application afin d'appliquer des règles de tentative d'accès particulières à un bean pour une demande, puis d'appliquer d'autres règles de tentative d'accès au même bean pour une demande différente.
La prise en charge des règles de tentatives d'accès au niveau méthode est obsolète dans WebSphere Application Server 6.0. Dans le cadre de cette configuration des tentatives d'accès, vous appliquez une règle aux méthodes de même portée qu'un module EJB, ce qui signifie que la règle devient la tentative d'accès par défaut pour toutes les demandes effectuées sur ces méthodes.
Remarques relatives à la conception des tentatives d'accès
Même si les règles de tentative d'accès peuvent être configurées au niveau de toute méthode d'un bean entity, certains attributs d'une règle ne peuvent être mis à niveau que par l'environnement d'exécution. Par exemple, la concurrence et la tentative d'accès ne sont utilisés que pour les beans entity CMP lorsque la méthode ejbLoad est pilotée afin d'ouvrir une connexion et de lire des données à partir d'une ressource donnée. Ces données sont placées en cache est permettent de piloter les requêtes appropriées lors de l'appel de la méthode ejbStore. Les indications de lecture anticipée ne sont utilisées que durant l'exécution d'une méthode finder pour un bean. L'incrément de collection et l'incrément de pré-extraction du gestionnaire de ressources ne sont utilisés que pour les localisateurs de plusieurs objets. La configuration de règles au niveau de méthodes qui n'utilisent pas de règles n'est pas une erreur. Seuls certains attributs d'une règle sont utilisés même si la règle est appliquée correctement à une méthode. Toutefois, la configuration de règles non nécessaires dans une application complique la conception d'une application ainsi que sa maintenance.
Tentative d'accès avec les beans entity BMP
La fonctionnalité déclarative de la tentative d'accès vous offre en tant que développeur de beans entity CMP de grandes possibilités. Vous pouvez fournir des conseils sur le mode de gestion des détails de persistance du produit sans qu'il lui soit nécessaire de gérer la logique de persistance au sein de l'application. Toutefois, il existe des situations dans lesquelles il peut être nécessaire de développer des beans entity BMP. Étant donné que la seule différence significative entre les composants BMP et CMP consiste à fournir la logique de persistance, les beans entity BMP doivent pouvoir exploiter les indications de tentative d'accès, tout comme le fait le produit pour le compte des beans entity CMP. Les beans entity BMP qui utilisent le service de tentative d'accès prennent part au profilage d'application. C'est-à-dire que la valeur des attributs de tentative d'accès peut différer de demande en demande, permettant au bean entity BMP de modifier en toute transparence sa stratégie de persistance.
Vous pouvez appliquer les règles de tentative d'accès aux méthodes de bean entity BMP ainsi que les méthodes de bean entity CMP. Etant donné que les indications de tentative d'accès ne sont pas contractuelles, il existe aucune obligation pour un bean entity BMP de les exploiter. Les beans entity BMP sont censés utiliser ces attributs de tentative d'accès qui sont importants pour ce bean particulier.
La règle de tentative d'accès en cours est lié à l'espace de nom java:comp pour un bean entity BMP particulier. Cette règle est active uniquement lors de la durée de l'appel de méthode pendant lequel la règle de tentative d'accès a été extraite. Dans un scénario standard, vous pouvez placer en cache le type d'accès lors de l'appel de la méthode ejbLoad afin que les actions appropriées soient prises lors de l'appel de la méthode ejbStore.
Meilleures pratiques pour les tentatives d'accès
Lors de l'application des règles de tentative d'accès à des méthodes d'EJB, tenez compte des éléments suivants.
- Commencez par configurer la règle de tentative d'accès par défaut d'une entité. Une fois que votre application est créée et démarrée, vous pouvez paramétrer certains chemins d'accès de votre application à l'aide du profilage d'application ou d'une règle de tentative d'accès au niveau méthode.
- Ne mélangez pas les types d'accès. Evitez d'utiliser des stratégies pessimistes et optimistes dans une même transaction. Pour la plupart des bases de données, les stratégies pessimistes et optimistes utilisent différents niveaux d'isolement. Il se peut que plusieurs connexions à la base de données soient établies, ce qui vous empêche de bénéficier des meilleures performances offertes par le partage des connexions.
- Soyez prudent lors de l'application de la règle wsPessimisticUpdate-NoCollision. Cette stratégie ne garantit pas l'intégrité des données. Aucun verrou de base de données n'étant conservé, les mises à jour des transactions simultanées peuvent s'écraser mutuellement. N'utilisez cette stratégie que si vous êtes certain que la tentative de mise à jour du système de stockage permanent ne sera effectuée que par une transaction à la fois.
Pour plus d'informati²ons sur les tentatives d'accès JPA (Java Persistence API), voir la rubrique correspondante.