mercredi 28 janvier 2009

Transaction déclarative dans Spring & RuntimeException

L'un des avantages de Spring est sa capacité de gérer les transactions de façon déclarative! évident !

J'ai eu (encore une autre fois) un appel d'urgence d'un client à ce propos.

L'urgence était au stade panique : « … le transactionnel de Spring avec Hibernate et JdbcTemplate, ça marche pas !, L'application a fait un débit d'un compte, a eu un problème lors du l'inscription du crédit, et n'a pas fait un « roll back » sur le débit, …

Conclusion : Spring ne sait pas gérer les transactions !! »

Un blasphème selon la communauté des « Springiens »

Une fois sur place, je commence par vérifier la « règle numéro 1 » de bon voisinage dans une transaction : l'information en cas de problème !

Je commence par la couche DAO, et je remonte petit à petit, et patiemment...

Premier constat : l'un des développeurs « catch » des exceptions sql et ne lève pas à la place une RuntimeException, il fait du log...

Second constat : un autre développeur « catch » des exceptions et lève à la place des exceptions simple de type Exception.

Une fois ces deux points corrigés, le miracle se produit : Spring gère très bien les transactions déclaratives

Morale de l'histoire : il ne suffit pas de bien faire les déclarations, que ce soit par des annotations ou bien par l'ajout de ce tag XML comme suit

<bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager" lazy-init="true">

<property name="sessionFactory" ref="sessionFactory" />

</bean>

<bean id="txProxyTemplate" abstract="true"

class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">

<property name="transactionManager" ref="transactionManager"/>

<property name="transactionAttributes">

<props>

<prop key="save*">PROPAGATION_REQUIRED</prop>

<prop key="remove*">PROPAGATION_REQUIRED</prop>

//

</props>

</property>

</bean>


Mais, le plus important c'est de savoir que dans ce mode Spring va réaliser le rollback si une des méthodes lève une exception non gérée de type RuntimeException

(Cela rappelle les débuts des EJB et des arguments avancés par leurs défenseurs)


Rappelons que cette façon de faire pourra être modifiée, mais ceci est un autre sujet ...

NB du 07/02/2009 : un article à lire : Transaction strategies: Understanding transaction pitfalls

vendredi 16 janvier 2009

Maîtriser son environnement de développement, le premier pas vers une plus grande productivité

J'ai eu l'occasion en l'espace d'une journée d'intervenir dans deux environnements différents, mais dans le cadre de la phase pré-production : assister 2 équipes dans la résolution de problèmes de dernières minutes avant le lancement !

Le premier cas : le matin, auprès d'une équipe de jeunes développeurs motivés maitrisant Eclipse version ganymade, l'outil de gestion de version Subversion intégré à Spring, l'outil Jira pour le suivi des bugs, cruisecontrol pour le build continue, … tous les plugins nécessaires ont été installés (SVN, Maven, SpringIde, Hibernate tools, ).

Le second cas : l'après midi, une équipe exploitant l'IDE Jdeveloper 11g, pas d'outil de suivi de bugs …

Les équipes avaient le même niveau d'un point de vue conceptuel, la maitrise même du langage Java et de la plateforme Java EE,

Dans les 2 cas on trouve les mêmes sujets: application de gestion en mode web, exploitant les framworks classiques Spring, Hibernate, pour l'un c'est du JSF et pour l'autre c'est du JSP/Struts, il ne s'agit ni de SOA, ni de SaaS, ni de PaaS ou d'un autre Buzz, les choses s'articulaient simplement autour de la notion de CRUD.

De point de vue productivité, le contraste, était frappant :

  • la première équipe a réalisé plus du double du travail que la seconde (et ça ne pourrait pas être expliqué par la lenteur de Jdeveloper),

Cela m'a permit de prendre valider, encore une autre fois, les constats suivants :

- Maitriser les raccourcis clavier (shortcut keys) de votre IDE , connaitre toutes les techniques de navigation efficace dans votre code, trouver un élément à la vitesse de la pensé ! ,

- Lier directement l'IDE à l'outil de gestion de version permet de gagner un temps appréciable (surtout en temps de crise)

- Automatiser les tâches répétitives (pas seulement la compilation, mais aussi le transfert de fichiers du développent vers de la pré-prod par exemple, rend le travail des équipes plus fluides en éliminant les phases d'hésitations et de vérifications …

- Dans le développement du code source, observer scrupuleusement la règle des 30secondes (on doit être capable de comprendre la logique d'une méthode en mois de 30s) permet d'aller plus vite pour fixer un bugs (même sous le stress)!


En plus, lorsque l'équipe est habituée à la responsabilité collective "du code source", les choses vont mieux..

En théorie, il n'y pas de différence entre pratique et théorie

Dans la pratique si.

vendredi 9 janvier 2009

PC payable à l'usage : est que Microsoft va pouvoir Breveter le concept

Il parait que non (pour l’instant) :
L'USPTO (office américain des brevets) a rejeté la demande de brevet concernant : « la facturation à l’usage des PC », déposée par Microsoft
La décision définitive n’est pas encore prononcée,
Que va faire Microsoft pour rendre « brevetable » ce concept,
Mais surtout qu’est ce qui se cache derrière cette manœuvre
A suivre ...

mercredi 7 janvier 2009

Java: Quelles « résolutions technologiques » pour 2009

La question de proposer des « résolutions technologiques » de l’année 2009 est la suivante :

Quelles sont les technologies java qui ont atteint une certaine maturité nous permettant de les utiliser dans des projets réels, et d’investir du temps à les connaitre et les maitriser

Sans regretter ce choix quelques mois après

J’avoue que la question est difficile, mais la tentation est grande de se lancer des résolutions en ce début d’année (ça serait plus facile à faire le 31 décembre)

Je propose :

1) OSGI (SpringDM) en préparation d’un monde "dynamique"

2) Groovy/grails sous l’égide de Spring

3) Android

4) JavaFX

5) EclipseLink en remplacement de Hibernate qui stagne

6) RAP (Eclipse)

7) SCA vers un monde de services (Spring est présent là aussi)

8) JBPM 4 & BPMN

9) GoogleAPPs (s’il adopte java, c'est fait depuis début Avril 2009)

10) SCALA (si j’ai encore du courage en fin d'année...)


Mais, tout dépendra des projets, du temps, de la détermination et de la fameuse crise...

Architecte SOA & Professionnel Open Source Headline Animator

 
Khaled BEN DRISS
Cloud Computing, SOA et Web 2.0 : Des sujets techniques sur SOA et l'Open Source : de Java & .Net, PHP5, Symfony, à SaaS / PaaS en passant par Azure, google appengine, le BPM, la Modélisation et d'autres sujets du coté du serveur et cloud computing.