new Blog("jclagache");

Client WCF et HTTP Basic Authentification

2011-05-20T11:43:00.014+02:00

WCF propose 2 protocoles pour cela : BasicHttpBinding et WSHttpBinding avec des caractéristiques différentes. Parmi celles-ci, la version SOAP des messages échangés doit être de version SOAP 1.1 pour BasicHttpBinding et SOAP 1.2 pour WSHttpBinding.
En partant du principe, que le web service cible est implémenté en SOAP 1.2, la seule solution devient WSHttpBinding. Sauf que … WSHttpBinding impose soit une sécurité sur le transport (SSL) ou sur le message (certificat X.509). Il n’existe donc aucune solution dans WCF pour utiliser un service web basé sur HTTP Basic Auth sans protection (très mauvaise pratique, je l’accorde …).
La seule solution est donc un CustomBinding surchargeant BasicHttpBinding en lui imposant comme version de message SOAP 1.2.

public class MyBasicHttpBinding : BasicHttpBinding
    {
        public override BindingElementCollection CreateBindingElements()
        {
            Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;
            Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;
            BindingElementCollection bc = base.CreateBindingElements();
            bc.Remove(bc.Find<textmessageencodingbindingelement>());
            //Transport binding element must be the last
            bc.Insert(0, new TextMessageEncodingBindingElement { MessageVersion = MessageVersion.Soap12 });
            return bc;
        }
    }

Pour le client :

var client = new MyWebserviceClient(new MyBasicHttpBinding(), new EndpointAddress("http://localhost:8090/MyWebservice"));
client.ClientCredentials.UserName.UserName = "my_user";
client.ClientCredentials.UserName.Password = "my_key";
client.doSomething();

Spring comme provider JPA au sein d’un conteneur EE5

2011-04-05T14:46:00.001+02:00

Notamment dans JBoss 5, cela pose un problème. En effet, le conteneur va scanner l’ensemble des librairies pour trouver le ou les fichiers de définitions des “persistence units” (META-INF/persistence.xml). Or, lorsque l’on souhaite que ce soit Spring qui gère la création de l’”EntityManagerFactory”, ce fichier de définition peut être très succinct :

<persistence xmlns=&<persistence xmlns="http://java.sun.com/xml/ns/persistence" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence 
    http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd" 
    version="2.0">
 
 <persistence-unit name="myPersistenceUnit">
  <class>model.MyEntityClass</class>  
 </persistence-unit>
  
</persistence>

Cette description ne permettra pas au conteneur EE5 de démarrer cette “persistence unit” en l’absence de source de données.
Par exemple, sous JBoss 5 le serveur indiquera qu’une spécification n’est pas respectée :

Specification violation [EJB3 JPA 6.2.1.2] - You have not defined a non-jta-data-source for a RESOURCE_LOCAL enabled persistence context named: myPersistenceUnit

La solution consiste a renommer le fichier persistence.xml de telle sorte qu’il ne soit pas pris en compte par le serveur (exemple : jpa-persistence.xml).
Mais cela ne suffit pas : le conteneur va aussi scanner toutes les classes à la recherche de l’annotation @PersistenceContext et sera incapable de charger la “persistence-unit” correspondante.
Là, l’attribut metadata-complete de l’élément web-app du fichier de configuration web.xml permet de préciser au conteneur de ne pas prendre en compte les annotations Java EE parce qu'elles sont gérées pas un autre mécanisme (Spring en l’occurrence dans notre cas).

<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5" metadata-complete="true">
</web-app>

L’ Agile Tour 2010 - Rouen

2010-10-28T14:28:00.004+02:00

Grâce au soutient du Normandy JUG, L’Agile Tour 2010 faisait une étape à Rouen ce 27 octobre dans les locaux du cesi à Mont Saint Aignan. C’était pour moi l’occasion de clarifier tous ces termes qui inondent la littérature sur la gestion de projet et l’agilité : “backlog”, “sprint”, “burdown chart”, etc …
Je vais pas mentir, j’ai rater la keynote de 13h30 … et je penses que cela a été préjudiciable pour la suite. En effet, j’ai eu l’impression de rentrer tout de suite dans le vif du sujet sans réel vue globale de haut niveau, sans comparaison avec d’autres modèles de gestion de projet ou plutôt LE modèle de gestion de projet qui a trôné pendant des années : le cycle en V.

L’adoption de l’agilité par les usages – Xavier Warzee

Je me suis trompé de salle … mais c’est trop tard, le speakeur commence. Les logos “Microsoft” et “MSN” sur le rétro projecteur me font penser que je vais avoir droit à une présentation commerciale de Visual Studio Team System. Et bien non, Xavier Warzee présente et explique ce qui fait le succès d’un taskboard : l’interactivité par le touché. Il est scientifiquement prouvé que la collaboration est plus efficace par l’approche tactile (touch). Ainsi, un tableau avec des post-it est un moyen très efficace d’organiser ses backlogs et tasks avec un public qui n’est plus que spectateur mais aussi acteur et appréhende cet exercice comme un jeu. Il faut cependant dématérialiser cette pratique pour d’une part conserver un historique des changements et éviter une double saisie vers le SI.
Xavier Warzee nous présente alors les solutions Microsoft face à cette demande :

Urban Turtle : l’outil de Pyxis qui s’interface avec TFS pour le planning board et la gestion de product backlog est aussi disponible sur une tablette à écran tactile sous Windows 7.
Team Table et TFS 2010 : Microsoft Surface et TFS collaborent pour fournir un plan interactif tactile de post-it virtuels pour les daily meeting.

Les fabricants planchent sur des versions en 3D, où les utilisateurs manipulent ces métaphores (post-it) dans l’espace. Bon, si je peux comprendre l’intérêt de ces tableaux virtuels pour la collaboration, je doute qu’une infrastructure à la “Minority Report” soit indispensable …

Intégration continue – Dimitri Vaeli

Le programme annonçait “Une approche imagée sur l’éligibilité et la contractualisation Agile par Laurent Morisseau”. Il a certainement été précisé lors de la keynote que Laurent Morisseau n’était pas là et que sa présentation était remplacée … C’est Dimitri Vaeli, d’eXo Platform, qui reprend une version actualisée et étoffée semble t’il d’une précédente présentation sur le sujet lors du Normandy JUG du 16/09/2009. Au menu, une des composantes de l’agilité : l’intégration continue (même si le concept existait bien avant la création de la méthode agile). L’intégration continue consiste à vérifier de manière systématique (au commit et(ou) à intervalle régulier) la non régression du logiciel. Cela passe par une automatisation complète de la phase de build (compilation, tests unitaires, analyse qualité, tests de déploiement, d’intégration, génération de la documentation, packaging et publication). Même si le concept m’est plutôt familier, j’ai pu noter quelques nom d’outils que je ne connaissais pas comme GreenPepper de … Pyxis. Mais là on n’est plus du tout en collaboration avec TFS mais plutôt avec les outils d’Atlassian. Déjà convaincu de la qualité et efficacité des autres outils (JIRA, Confluence, …) de cet éditeur, je ne peux qu’approfondir l’utilisation de GreenPepper. D’ailleurs, il est fort probable que l’ALM d’eXo Platform soit géré par ces outils … L’une des difficultés dans l’intégration continue sont les tests ou plutôt comment distinguer les tests unitaires, des tests d’intégration. Pour moi les frontières entre ces tests sont souvent floues et poreuses. Dimitri Vaeli ne m’a pas éclairé davantage, c’est en effet un exercice difficile aussi d’après lui. Nous sommes tout de même arrivé à la conclusion suivante :

dans les test unitaires, on teste une classe unitairement. On “Mock” les objets en relation avec la classe à tester pour se concentrer uniquement sur les algorithmes qui la compose.
dans les tests d’intégration, ces relations doivent être implémentées. Ces tests doivent être répartis suivant le degré de qualité que l’on veut vérifier. Ainsi, ces tests d’intégration peuvent à la fois prendre la forme de tests JUnit (ou TestNG) mais aussi de tests Selenium (ou Abbot) pour une couverture encore plus élargie.

Optimiser le retour sur investissement de votre produit avec une bonne priorisation de votre backlog – Céline Stauder

Je suis pour l’instant un peu déçu : même si j’ai apprécié les 2 premières présentations, je n’ai toujours pas clarifier la vision que je me faisait de l’agilité. Je n’ai certainement pas choisis les présentations adéquates pour ce genre de questionnement. Céline Stauder de CLT Services propose une vision orientée service produits de la méthode et dès les premiers slides de sa présentation, je sens que c’est ce point de vue qui va m’éclairer. Tout d’abord quelques définitions :

product backlog : ensemble de user stories priorisées
product owner : le “maitre” du projet
user story (US) : fonctionnalité vue par l’utilisateur. Par exemple, en tant que rôle X dans le produit je veux pouvoir faire ça.

Céline Stauder détaille ensuite les méthodes de priorisation des US. C’est cette priorisation par “backlog en map” qui va donner le roadmap. Les US les plus pertinentes seront en effet dans la première release. La méthode présentée est la priorisation relative de Mike Cohn. L’idée est de prendre une US de référence et de comparer les autres US par rapport à celle-ci. On arrive ensuite à une classification des US dans le backlog :

Conclusion

Suivant ce que j’attendais de cette après-midi, je penses qu’assister à d’autres sessions m’aurait été plus profitable, notamment l’Introduction à Scrum par Guillaume Lours et l’atelier de Planning Poker de Youen Chéné. Cependant, les 3 présentations auxquelles j’ai pu assisté m’ont toutes semblées intéressantes et toutes animées par des personnes passionnées. Ce type d’évènement est fait par des agilistes, ~~pour des agilistes~~ pour tout public même si quelques notions de base sur la méthode sont préférables pour profiter des différents speakeurs. En tout cas, une belle initiative du Normandy Agile Group.

Intégration de l’API Zoho Report dans Spring

2009-12-10T17:46:00.003+01:00

Zoho Report permet de réaliser facilement en ligne des rapports et graphiques efficaces.
Une API REST est disponible pour soumettre ou récupérer des données dans ou depuis Zoho Report. Ce format n’est pas le plus adapté pour manipuler un nombre important de données organisées au sein d’une base de données. Zoho CloudSQL permet d’effectuer ces manipulations par requête SQL. Un driver JDBC vient compléter le tout pour offrir une véritable connectivité à cette base de donnée “on the cloud”.
Cependant, CloudSQL et donc le driver JDBC ne permettent, pour l’instant, que de la récupération de données (SELECT).
Pour utiliser complètement les possibilités de Zoho Report, le mieux est donc d’utiliser les librairies clientes disponibles (Java, Python et Google App Engine).
Pour Java, pour utiliser la librairie, il faut :

télécharger la librairie sur cette page
avoir un compte Zoho (LOGINNAME,PASSWORD)
demander une clé API (APIKEY)
une base de donnée crée (DATABASENAME) avec au mois une table (TABLENAME)

ReportClient rc = new ReportClient(APIKEY);
rc.login(LOGINNAME,PASSWORD);
String uri = getURI(LOGINNAME,DATABASENAME,TABLENAME);
rc.addRow(uri, new HashMap(), null);

Le but ici est d’utiliser Spring pour simplifier la gestion du client et de ses constantes de configuration (APIKEY, LOGINNAME, PASSWORD et DATABASENAME) :

ZohoReportClientWrapper rc = (ZohoReportClientWrapper) ctx.getBean("zohoClient");
rc.login();
rc.addRow("sampleTable", new HashMap());

Avec comme fichier de configuration Spring :


<bean id="zohoConfig" class="ZohoConfig">
<property name="apiKey" value="yourAPIKey"/>
<property name="databaseName" value="yourDBName"/>
<property name="loginName" value="yourZohoLogin"/>
<property name="password" value="yourZohoPasswd"/> 
</bean>

<bean id="zohoClient" class="ZohoReportClientWrapper" init-method="init">
<property name="config" ref="zohoConfig"/> 
</bean>

Pour cela, j’ai crée un projet Google : spring-zohoreport

Google App Engine (GAE) : création d'un environnement de développement

2009-10-21T17:02:00.005+02:00

Installation et configuration pas à pas d'un environnement de développement java pour Google App Engine.

Installation du SDK Java

Google App Engine supporte Java 5 et Java 6. Cependant, l'application tournera sous Java 6 dans App Engine. Il est donc naturellement préférable que l'environnement de développement soit configuré en Java 6.

Tips : localisation des SDKs sur le disque
Créer un dossier "SDKs" sur votre disque dur. Par exemple, sous Windows, je l'ai créer sous C:\SDKs.
Créer une variable d'environnement pour ce dossier (SDKS_HOME).
C'est dans ce répertoire SDKS_HOME que vous pourrez installer les différentes versions de SDK.
Par exemple sous Windows, pour créer des variables d'environnement il faut soit aller dans Panneau de Configuration -> Système ou clique droit sur le bureau dans Poste De Travail -> Propriétés.
Cliquer alors sur l'onglet Avancé puis sur le bouton Variables d'environnement.
Entrer les variables suivantes dans Variables Systèmes :
SDKS_HOME = C:\SDKs
JAVA_HOME = %SDKS_HOME%\jdk1.6.0_16
Rajouter %JAVA_HOME%\bin à la variable PATH
Tout ceci permet de "switcher" rapidement de version de Java,
simplement en modifiant la variable JAVA_HOME.

Télécharger et installer le Java SE Development Kit (JDK). Pour vérifier l'installation, vérifier le numéro de version retourné par ces lignes de commande.

java -version

javac -version

Installation d'Eclipse et du Plugin Google

Un plugin Google pour Eclipse est disponible. Celui-ci est disponible pour les versions Eclipse 3.3 (Europa), Eclipse 3.4 (Ganymede) and Eclipse 3.5 (Galileo). Le dernière version Eclipse à l'écriture de ce post est la version 3.5 (Galileo).
Télécharger et installer Eclipse 3.5 (Galileo) Il est préférable de choisir le package Eclipse IDE for Java EE Developers pour profiter aussi du plugin Web Tools Platform (WTP).

Lancer Eclipse pour installer le Plugin Google par le Software Update d'Eclipse.

Selectionner Help -> Install New Software
Dans la zone de texte Work with taper http://dl.google.com/eclipse/plugin/3.5
Cliquer sur le bouton Add puis sur OK dans la zone de dialogue.
Cocher les composants "Google Plugin for Eclipse 3.5" et "Google App Engine Java SDK"("Google Web Toolkit SDK" pourra être installer plus tard si nécessaire).
Une fois l'installation terminée Eclipse doit être redémarré.

Voilà, il faut maintenant se lancer en créant son premier projet.

Traitement asynchrone avec une api REST

2009-05-27T15:25:00.009+02:00

Une des critiques faite sur REST est le fait de son attachement au protocole HTTP. Ce protocole est "déconnecté" : il est impossible de reprendre une connexion précédente. Cela pose un problème dans le cadre de longs traitements asynchrones et de notifications.

Une possibilité pour palier à cette faiblesse est de considérer elle aussi cette transaction comme une ressource. Cette ressource est retournée immédiatement au client suite au premier appel. Ensuite, le client pourra récupérer l'état de cette transaction. Par exemple, supposons que nous souhaitons lancer un batch "batch1" de manière asynchrone :


GET /batchs/batch1  HTTP/1.1
Host: xyz.com
Content-Type: application/xml; charset=utf-8


HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
Location: /transactions/1234
http://xyz.com/transactions/1234

La réponse est immédiatement renvoyée et contient l'URI de la transaction utilisée. Le client peut consulter cette ressource pour connaitre le status de son traitement en cours.


GET /transactions/1234 HTTP/1.1
Host: xyz.com
Content-Type: application/xml; charset=utf-8


HTTP/1.1 200 OK
Content-Type: application/xml; charset=utf-8
Content-Length: nnn

 batch1
 In Progress

Internationalisation (i18n) en Javascript

2009-02-06T17:42:00.010+01:00

Difficile de gérer le multilinguisme (i18n) en Javascript ! Et pourtant, on est souvent tenté de rapidement écrire dans son code des messages destinés à l'utilisateur. La gestion a posteriori de plusieurs langues devient alors un casse tête. Mieux vaut anticipé et externaliser ses libellés.

var labels_fr =  {
'hello' : 'Bonjour {0}, tu as {1} ans',
'quit' : 'Quitter ?'
}
var labels_en =  {
'hello' : 'Hello {0}, you are {1}',
'quit' : 'Quit ?'
}

La classe ci-dessous permet d'obtenir simplement le libellé souhaité en fonction de la langue :

var i18n = new I18n();
i18n.load(labels_fr);
i18n.translate('hello','JC', '33');

Plus propre, non ?
La classe en question (UPDATE 18/10/2010 : prise en compte de plusieurs patterns) :

/**
* I18n est une classe permettant d'obtenir un libellé
* caractérisé par une clé dans une map contenant un
* ensemble de libellés traduits dans la langue choisie
* @constructor
*/
var I18n = function(){}

/**
* Charge la map de clés/libellés
* @param {Object}  translations Les clés/libellés traduits
* @constructor
*/
I18n.prototype.load = function(translations) {
this._translations = translations;
}

/**
* Remplace les nombres entre accolades ({0}) par les
* chaînes de caractères passées en paramètre
* exemple  : _format('Hello {0} ! ', 'guy') => Hello guy !
* @param {String}  format La chaîne de caractère à formater
*/
I18n.prototype._format = function(format) {
var args = arguments[1];
return format.replace(/\{(\d+)\}/g, function(m, i){
return args[i];
});
}

/**
*  Retrouve le libellé correspondant à la clé passée en paramètre
* et le formate en fonction des paramètres supplémentaires
* exemple  : translate('hello', 'guy') => Hello guy !
* @param {String}  key La clé à traduire
*/
I18n.prototype.translate = function(key) {
if (typeof(this._translations)!='undefined' && this._translations[key]) {
return this._format(this._translations[key],Array.prototype.slice.call(arguments,1));
}
return key;
}

JSF (MyFaces) et TimeZone

2008-10-02T15:20:00.006+02:00

Les spécifications JSF font que le fuseau horaire (timezone) par défaut d'une conversion Date -> String est le GMT.
Celui du serveur n'est pas pris en compte.
Pour MyFaces, ces spécifications sont respectées depuis les versions supérieures à 1.1.0


package javax.faces.convert;
...
public class DateTimeConverter implements Converter, StateHolder {
...
  private static final TimeZone TIMEZONE_DEFAULT = TimeZone.getTimeZone("GMT");
...
}

Ainsi, il faudrait préciser le fuseau horaire dans toutes les pages affichant des dates si on souhaite en utiliser un autre.


<h:outputText value="#{bean.date}">
 <f:convertDateTime timeZone="Europe/Paris"/>
</h:outputText

Fastidieux!
Le plus simple est d'écrire son propre DateTimeConverter :


import java.util.TimeZone;
import javax.faces.convert.DateTimeConverter;
public class MyDateTimeConverter extends DateTimeConverter {
  public MyDateTimeConverter() {
    super();
    setTimeZone(TimeZone.getDefault());
  }
}

et de faire en sorte qu'il devienne le converter par défaut :


<converter>
<converter-for-class>java.util.Date</converter-for-class>
<converter-class>MyDateTimeConverter</converter-class>
</converter>

Utilisation avancée du plugin Maven Hibernate 3

2008-06-03T16:36:00.015+02:00

Le plugin Maven Hibernate 3 permet d'intégrer facilement Hibernate 3 au sein d'un projet géré par maven. Ce plugin est régulièrement maintenu et sa communauté réactive mais on peu cependant déplorer une documentation succincte.
On y trouve en effet des exemples que pour des cas simples d'utilisation.
Par exemple, on y trouve comment générer un schéma pour une base de donnée avec un seul fichier de configuration mais comment faire pour générer des schémas pour plusieurs bases de données, chacune possédant son propre fichier de configuration .hbm.
Pour cela, il faut appeler plusieurs fois hbm2ddl :


 org.codehaus.mojo
 hibernate3-maven-plugin
 2.2-SNAPSHOT
 
  
   generate-database-1
   process-test-resources
   
    hbm2ddl
   
   
    
     target/classes/hibernate1.cfg.xml
     target/classes/jdbc1.properties
    
   
  
  
   generate-database-2
   process-test-resources
   
    hbm2ddl
   
   
    
     target/classes/hibernate2.cfg.xml
     target/classes/jdbc2.properties
    
   
  
 
 
  
   ${jdbc1.groupId}
   ${jdbc1.artifactId}
   ${jdbc1.version}
  
  
   ${jdbc2.groupId}
   ${jdbc2.artifactId}
   ${jdbc2.version}

Cette logique reste vraie avec les autres "goals".

Problème de validation XML avec JAXP

2008-03-27T15:15:00.008+01:00

L'api JAXP permet l'analyse et la transformation de documents XML. Une implémentation de JAXP est disponible dans JAVASE 5.0 mais il est aussi possible d'utiliser l'implémentation fournie par Apache Xerces.
Pour analyser le fichier data.xml avec un parser SAX :


SAXParserFactory spfactory = SAXParserFactory.newInstance();
spfactory.setNamespaceAware(true);
SAXParser saxparser = spfactory.newSAXParser();
saxparser.parse(new File("data.xml"));

Et avec un parser DOM :


DocumentBuilderFactory dbfactory = DocumentBuilderFactory.newInstance();
dbfactory.setNamespaceAware(true);
DocumentBuilder domparser = dbfactory.newDocumentBuilder();
domparser.parse(new File("data.xml"));

La fonctionnalité qui nous intéresse ici est la validation d'un document par rapport à un schéma.


DocumentBuilderFactory dbfactory = DocumentBuilderFactory.newInstance();
dbfactory.setNamespaceAware(true);
dbfactory.setXIncludeAware(true);

DocumentBuilder parser = dbfactory.newDocumentBuilder();
Document doc = parser.parse(new File("data.xml"));

DOMSource xmlsource = new DOMSource(doc);

SchemaFactory wxsfactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);

//load a W3C XML Schema
Schema schema = wxsfactory.newSchema(new File("myschema.xsd"));

// create a validator from the loaded schema
Validator validator = schema.newValidator();

//validate the XML instance
validator.validate(xmlsource);

Si cet exemple fonctionne avec l'implémentation fournie avec JAVASE 5.0, une exception est toujours levée avec Xerces :


Exception in thread "main" org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'root'.

En effet, l'implémentation Xerces de Validator#validate ne semble pas supporter un objet de classe DOMSource en paramètre.
Pour contourner ce problème, il faut utiliser la fonctionnalité de transformation de JAXP et transformer notre document DOM(DOMSource) en Stream(StreamSource).


DOMSource xmlsource = new DOMSource(doc);
StringWriter writer = new StringWriter();
StreamResult result = new StreamResult(writer);
TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();
transformer.transform(xmlsource , result);
validator.validate(new StreamSource(new StringReader(result.toString())));

Pour aller plus loin : http://issues.apache.org/jira/browse/XERCESJ-1163

Sticky sessions

2008-02-05T11:01:00.001+01:00

Dans un environnement multi-serveurs (cluster), le mécanisme de sticky session (affinité de session) assure qu'un client qui a ouvert une session sur un serveur sera toujours aiguillé vers ce même serveur durant sa session.
Par opposition, la réplication de session permet de garder sa session quelque soit le serveur sur lequel l'utilisateur est aiguillé.

Oracle rachète BEA

2008-01-17T13:32:00.000+01:00

Ca se tramait depuis un certain temps mais c'est maintenant officiel :

Oracle to Acquire BEA Systems

L'un des 2 serveurs d'application OC4J ou Weblogic Server devrait passer à la trappe.

De même, on peut se demander comment va se positionner la nouvelle entité par rapport à Workshop concurent direct de JDevelopper.

En tout cas, ce rachat sucite de nombreuses réactions dont celles de Rod Johnson et Gigaspace qui nous encouragent à s'affranchir de l'architecture j2ee dont les 2 seuls concurrents directs sont maintenant Oracle et IBM.

Niveau d'isolement des transactions avec les EJB

2008-01-15T12:45:00.000+01:00

C'est souvent trop tard qu'on commence à se pencher sérieusement sur certains concepts. Celui-ci est souvent occulté quand on développe un module EJB mais cet oubli peut conduire à des incompréhensions. L'abstraction de l'architecture J2EE peut alors se montrer trompeuse ...

L'isolement des transactions (le "I" dans les propriétés ACID), représente un concept et des mécanismes permettant d'assurer l'intégrité d'une base de données pouvant être accedée et(ou) mise à jour par un ensemble de clients simultanément.

En vue d'un déploiement au sein d'un conteneur d'EJB, la bonne pratique veut que ces transactions soient déclarées "déclarativement" dans les différents descripteurs de déploiement.
Dans cette optique, le niveau d'isolement peut être défini pour l'EJB ou pour une méthode en particulier.
Les différents niveaux d'isolement et leurs caractéristiques sont résumés ici.

TRANSACTION_SERIALIZABLE

La transaction obtient les privilèges exclusifs de lecture et d'écriture sur les données. Aucune autre transaction ne peut lire ou écrire les même données. Les "dirty reads", "nonrepeatable reads" et "phantom reads" sont donc exclues. Ce niveau d'isolation est le plus restrictif.

TRANSACTION_REPEATABLE_READ

La transaction ne peut modifier les données en cours de lecture par une autre transaction.Les "dirty reads" et "nonrepeatable reads" sont exclues. Les "phantom reads" peuvent subvenir. Les EJB ou méthodes utilisant ce niveau d'isolation ont les mêmes restrictions que le niveau TRANSACTION_READ_COMMITED et auront des données identiques pendant toute la transaction.

TRANSACTION_READ_COMMITTED

La transaction ne peut lire des données non commitées. Des données en cours de modification par une autre transaction ne peuvent pas être lues. Les "dirty reads" sont exclues mais les "nonrepeatable reads" et "phantom reads" peuvent subvenir.

TRANSACTION_READ_UNCOMMITTED

La transaction peut lire des données pas encore commitées par une autre transaction en cours.Les "dirty reads", "nonrepeatable reads" et "phantom reads" peuvent subvenir.

dirty reads
Séquence :
– A écrit un tuple
– B lit ce tuple
– A fait un rollback (restaurant l'ancienne valeur)
Conséquence :
– B a effectué un dirty read
– B possède une mauvaise valeur

nonrepeatable reads
Séquence :
– B lit un tuple
– A modifie ce tuple
– A fait un commit, rendant le changement permanent
Conséquence :
– B a effectué un non repeatable read
– B ne possède pas la bonne valeur du tuple
Si B refait une lecture de ce tuple, il aura une autre valeur

phantom reads
Séquence :
– A lit un ensemble de tuples
– B écrit un tuple qui aurait dû se trouver dans l'ensemble de A si B avait été plus rapide
Conséquence :
– A ne possède pas toute l'information qu'il cherchait
– Si A exécute la même requête à nouveau, les phantoms (nouveaux tuples) apparaissent