Liberty ne prend pas en charge la répercussion des transactions sortantes ou entrantes pour les interfaces distantes EJB. Par défaut, les beans EJB sont gérés par un conteneur et utilisent l'attribut de transaction Required. De ce fait, les définitions d'EJB existantes qui ne spécifient pas de propriétés container-transaction sont configurées par défaut pour utiliser des transactions même si celles-ci ne sont pas prises en charge.
Cette règle marque le code Java qui référence les annotations EJB suivantes indiquant l'utilisation d'interfaces métier ou home distantes :
javax.ejb.Remotejavax.ejb.RemoteHomeCette règle marque également les références ci-dessous dans le fichier ejb-jar.xml :
<remote/><business-remote/>
La spécification EJB nécessite des produits qui prennent en charge la répercussion des transactions sortantes pour continuer à envoyer un contexte de transaction null.
Ce contexte doit être refusé par les composants EJB qui utilisent les attributs de transaction Required (valeur par défaut), Mandatory ou Supports. Un client avec une transaction globale active ne peut pas démarrer un bean EJB avec les attributs de transaction par défaut si le client ou le serveur se trouve dans le profil Liberty.
Pour permettre au client de démarrer le bean EJB, modifiez le bean EJB de manière à utiliser l'attribut de transaction RequiresNew ou NotSupported. Bien que ces attributs autorisent le démarrage du bean EJB, le travail transactionnel effectué par le bean EJB n'est pas validé dans le cadre des transactions du client.
Notez que la propagation des transactions est prise en charge pour les interfaces EJB distantes qui s'exécutent sur la même machine virtuelle Java. Toutefois, vous ne pouvez le déterminer qu'en examinant le comportement des applications.
Souvent, les beans EJB 2.x configurent les interfaces distantes dans ejb-jar.xml, même si celles-ci ne sont pas utilisées.
Vous n'avez besoin d'interfaces distantes que si votre code s'exécute sur deux machines virtuelles Java différentes.
Dans le cadre de WebSphere, il s'agit de deux serveurs d'applications différents ou d'une application client et d'un serveur d'applications s'exécutant sur des machines virtuelles Java différentes.
Les informations CORBA dans une recherche d'EJB, comme les URL de fournisseur iiop://, indiquent également que des beans EJB distants sont utilisés.
Si vous référencez à l'aide d'une interface distante des beans EJB qui s'exécutent sur une même machine virtuelle, l'interface locale peut être utilisée et sera plus performante.
Si possible, remplacez les annotations @Remote par des annotations @Local et les annotations @RemoteHome par des annotations @LocalHome et testez tous vos scénarios de code.
De même, pour la configuration ejb-jar.xml, retirez les définitions <remote/> et <business-remote/> et testez tous les scénarios.
Alors que la propagation des transactions est prise en charge dans ce scénario, il est recommandé d'utiliser des interfaces locales pour améliorer les performances et éliminer l'idée que des méthodes peuvent être appelées en externe depuis la même machine virtuelle Java.
Pour les beans EJB requérant un accès distant, il est recommandé de les encapsuler dans un service Web. Voir Annotating an EJB bean to create a web service pour des instructions d'utilisation de WebSphere Application Server Developer Tools for Eclipse pour effectuer ces modifications de code. Une fois les beans EJB encapsulés dans des services Web, utilisez le client de service Web pour appeler le service Web d'EJB. Une fois le test effectué, vous pouvez retirer la configuration ou les annotations distantes d'EJB.
Pour plus d'informations sur des sujets connexes, voir :