Spring MVC 5

Spring MVC par l'exemple
- Partie 5 -
serge.tahe@istia.univ-angers.fr, avril 2006
springmvc - partie5, ST universit dAngers
1/73
1 Rappels
Nous poursuivons dans cet article le travail fait dans les prcdents :
Spring MVC par l'exemple partie 1 : [http://tahe.developpez.com/java/springmvc-part1]

Dans le dernier article, nous avons mis en oeuvre Spring MVC dans une architecture 3tier [web, metier, dao] sur un exemple
basique de gestion dune liste de personnes. Cela nous a permis dutiliser les concepts qui avaient t prsents dans les prcdents
articles.
Couche Interface Utilisateur[ui-web]
utilisateur
DispatcherServlet
1
Couche service
[service]
2
3
Controller
4
Couche d'accs
aux donnes
[dao]
Donnes
Modle Map
View
Dans la version 1, la liste des personnes tait maintenue en mmoire et disparaissait au dchargement de lapplication web. Dans la
version tudie ici, la liste des personnes est maintenue dans une table de base de donnes. Nous ne dvelopperons que les couches
[service] et [dao]. La couche [ui-web] reste celle qui a t dveloppe pour la version 1.
Nous dvelopperons lexemple tout dabord avec une base de donnes Firebird. Puis ensuite, nous prsenterons des versions pour
les SGBD Postgres, MySQL et SQL Server Express. Le tableau suivant indique au lecteur o se procurer librement ces SGBD et
des clients pour les administrer :
SGBD
Firebird
client(s) dadministration
site(s)
http://www.firebirdsql.org/
IBExpert :
http://www.ibexpert.com/
SQL Manager Lite pour Firebird :
http://www.sqlmanager.net/fr/products/ibfb/manager
Postgres
http://www.postgresql.org/
SQL Manager Lite pour Postgres :

http://www.sqlmanager.net/fr/products/postgresql/man
ager
MySQL
http://www.mysql.com/
http://www.easyphp.org/
SQL Manager Lite pour MySQL :

http://www.sqlmanager.net/fr/products/mysql/manager
SQL
Server
Express
http://msdn.microsoft.com/vstudio/express/
sql/
SQL Server Management Studio Express :

http://msdn.microsoft.com/vstudio/express/sql/downl
oad/
SQL Manager Lite pour SQL Server Express:

http://www.sqlmanager.net/fr/products/mssql/manager
2 Spring MVC dans une architecture 3tier Exemple 2 - Firebird

2.1
La base de donnes Firebird
2/73
Dans cette version, nous allons installer la liste des personnes dans une table de base de donnes Firebird. On trouvera dans le
document [http://tahe.developpez.com/divers/sql-firebird/] des informations pour installer et grer ce SGBD. Dans ce qui suit,
les copies dcran proviennent d IBExpert, un client dadministration des SGBD Interbase et Firebird.
La base de donnes sappelle [dbpersonnes.gdb]. Elle contient une table [PERSONNES] :
La table [PERSONNES] contiendra la liste des personnes gre par lapplication web. Elle a t construite avec les ordres SQL
suivants :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
CREATE TABLE PERSONNES (

ID
INTEGER NOT NULL,
"VERSION"
INTEGER NOT NULL,
NOM
VARCHAR(30) NOT NULL,
PRENOM
DATENAISSANCE DATE NOT NULL,
MARIE
SMALLINT NOT NULL,
NBENFANTS
SMALLINT NOT NULL
);
ALTER
ALTER
ALTER
ALTER
TABLE
TABLE
TABLE
TABLE
PERSONNES
PERSONNES
PERSONNES
PERSONNES
ADD
ADD
ADD
ADD
CONSTRAINT
CONSTRAINT
CONSTRAINT
CONSTRAINT
CHK_PRENOM_PERSONNES check (PRENOM<>'');

CHK_MARIE_PERSONNES check (MARIE=0 OR MARIE=1);
CHK_NOM_PERSONNES check (NOM<>'');
CHK_ENFANTS_PERSONNES check (NBENFANTS>=0);
ALTER TABLE PERSONNES ADD CONSTRAINT PK_PERSONNES PRIMARY KEY (ID);
lignes 2-10 : la structure de la table [PERSONNES], destine sauvegarder des objets de type [Personne], reflte la
structure de cet objet. Le type boolen nexistant pas dans Firebird, le champ [MARIE] (ligne 8) a t dclar de type
[SMALLINT], un entier. Sa valeur sera 0 (pas mari) ou 1 (mari).
lignes 13-16 : des contraintes dintgrit qui refltent celles du validateur de donnes [ValidatePersonne].
ligne 19 : le champ ID est cl primaire de la table [PERSONNES]
La table [PERSONNES] pourrait avoir le contenu suivant :
La base [dbpersonnes.gdb] a, outre la table [PERSONNES], un objet appel gnrateur et nomm [GEN_PERSONNES_ID]. Ce
gnrateur dlivre des nombres entiers successifs que nous utiliserons pour donner sa valeur, la cl primaire [ID] de la classe
[PERSONNES]. Prenons un exemple pour illustrer son fonctionnement :
3/73
- le gnrateur a actuellement la valeur 96
- double-cliquer sur [GEN_PERSONNES_ID]
- mettons lordre SQL ci-dessus (F12) ->

- la valeur obtenue est lancienne valeur du gnrateur +1
On peut constater que la valeur du gnrateur [GEN_PERSONNES_ID] a chang (double-clic dessus + F5 pour rafrachir) :
Lordre SQL
SELECT GEN_ID ( GEN_PERSONNES_ID,1 ) FROM RDB$DATABASE
permet donc davoir la valeur suivante du gnrateur [GEN_PERSONNES_ID]. GEN_ID est une fonction interne de Firebird et
[RDB$DATABASE], une table systme de ce SGBD.
2.2
Le projet Eclipse des couches [dao] et [service]
Pour dvelopper les couches [dao] et [service] de notre application avec base de donnes, nous utiliserons le projet Eclipse [springmvc-38] suivant :
Le projet est un simple projet Java, pas un projet web Tomcat. Rappelons que la version 2 de notre application va utiliser la couche
[web] de la version 1. Cette couche na donc pas tre crite.
Dossier [src]
4/73
Ce dossier contient les codes source des couches [dao] et [service] :
On y trouve diffrents paquetages :
[istia.st.springmvc.personnes.dao] : contient la couche [dao]
[istia.st.springmvc.personnes.entites] : contient la classe [Personne]
[istia.st.springmvc.personnes.service] : contient la classe [service]
[istia.st.springmvc.personnes.tests] : contient les tests JUnit des couches [dao] et [service]

ainsi que des fichiers de configuration qui doivent tre dans le ClassPath de lapplication.
Dossier [database]
Ce dossier contient la base de donnes Firebird des personnes :
[dbpersonnes.gdb] est la base de donnes.

[dbpersonnes.sql] est le script SQL de gnration de la base :
1. /******************************************************************************/
2. /***
Generated by IBExpert 2006.03.07 27/04/2006 10:27:11
***/
3. /******************************************************************************/
4.
5. SET SQL DIALECT 3;
6.
7. SET NAMES NONE;
8.
9. CREATE DATABASE 'C:\data\2005-2006\webjava\dvp-spring-mvc\mvc-38\database\DBPERSONNES.GDB'
10. USER 'SYSDBA' PASSWORD 'masterkey'
11. PAGE_SIZE 16384
12. DEFAULT CHARACTER SET NONE;
13.
14.
15.
16. /******************************************************************************/
17. /***
Generators
***/
18. /******************************************************************************/
19.
20. CREATE GENERATOR GEN_PERSONNES_ID;
21. SET GENERATOR GEN_PERSONNES_ID TO 787;
22.
23.
24.
25. /******************************************************************************/
26. /***
Tables
***/
27. /******************************************************************************/
28.
29.
5/73
30.
31. CREATE TABLE PERSONNES (
32.
ID
INTEGER NOT NULL,
33.
"VERSION"
INTEGER NOT NULL,
34.
NOM
35.
PRENOM
36.
DATENAISSANCE DATE NOT NULL,
37.
MARIE
SMALLINT NOT NULL,
38.
NBENFANTS
SMALLINT NOT NULL
39. );
40.
41. INSERT INTO PERSONNES (ID, "VERSION", NOM, PRENOM, DATENAISSANCE, MARIE, NBENFANTS) VALUES (1, 1,
'Major', 'Joachim', '1984-11-13', 1, 2);
'Humbort', 'Mlanie', '1985-02-12', 0, 1);
'Lemarchand', 'Charles', '1986-03-01', 0, 0);
44.
45. COMMIT WORK;
46.
47.
48.
49. /* Check constraints definition */
50.
51. ALTER TABLE PERSONNES ADD CONSTRAINT CHK_PRENOM_PERSONNES check (PRENOM<>'');
52. ALTER TABLE PERSONNES ADD CONSTRAINT CHK_NOM_PERSONNES check (NOM<>'');
53. ALTER TABLE PERSONNES ADD CONSTRAINT CHK_MARIE_PERSONNES check (MARIE=0 OR MARIE=1);
54. ALTER TABLE PERSONNES ADD CONSTRAINT CHK_ENFANTS_PERSONNES check (NBENFANTS>=0);
55.
56.
57. /******************************************************************************/
58. /***
Primary Keys
***/
59. /******************************************************************************/
60.
61. ALTER TABLE PERSONNES ADD CONSTRAINT PK_PERSONNES PRIMARY KEY (ID);
Dossier [lib]
Ce dossier contient les archives ncessaires lapplication :
On notera la prsence du pilote JDBC [firebirdsql-full.jar] du SGBD Firebird. Toutes ces archives font partie du Classpath du projet
Eclipse.
Dossier [dist]
Ce dossier contiendra les archives issues de la compilation des classes de lapplication :
2.3
2.3.1
[personnes-dao.jar] : archive de la couche [dao]

[personnes-service.jar] : archive de la couche [service]
La couche [dao]
Les composantes de la couche [dao]
La couche [dao] est constitue des classes et interfaces suivantes :

6/73
[IDao] est linterface prsente par la couche [dao]

[DaoImplCommon] est une implmentation de celle-ci o le groupe de personnes se trouve dans une table de base de
donnes. [DaoImplCommon] regroupe des fonctionnalits indpendantes du SGBD.
[DaoImplFirebird] est une classe drive de [DaoImplCommon] pour grer spcifiquement une base Firebird.
[DaoException] est le type des exceptions non contrles, lances par la couche [dao]. Cette classe est celle de la version 1.
Linterface [IDao] est la suivante :

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
package istia.st.springmvc.personnes.dao;
linterface a les mmes quatre mthodes que dans la version prcdente.
import istia.st.springmvc.personnes.entites.Personne;
import java.util.Collection;
public interface IDao {
// liste de toutes les personnes
Collection getAll();
// obtenir une personne particulire
Personne getOne(int id);
// ajouter/modifier une personne
void saveOne(Personne personne);
// supprimer une personne
void deleteOne(int id);
}
La classe [DaoImplCommon] implmentant cette interface sera la suivante :

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
package istia.st.springmvc.personnes.dao;
import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;
public class DaoImplCommon extends SqlMapClientDaoSupport implements
IDao {
// liste des personnes
public Collection getAll() {
...
}
// obtenir une personne en particulier
public Personne getOne(int id) {
...
}
// suppression d'une personne
public void deleteOne(int id) {
...
}
// ajouter ou modifier une personne
public void saveOne(Personne personne) {
// le paramtre personne est-il valide ?
check(personne);
// ajout ou modification ?
if (personne.getId() == -1) {
// ajout
insertPersonne(personne);
} else {
updatePersonne(personne);
}
}
// ajouter une personne
protected void insertPersonne(Personne personne) {
...
}
// modifier une personne
protected void updatePersonne(Personne personne) {
7/73
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
...
}
lignes 8-9 : la classe [DaoImpl] implmente linterface [IDao] et donc les quatre mthodes [getAll, getOne, saveOne,
deleteOne].
lignes 27-37 : la mthode [saveOne] utilise deux mthodes internes [insertPersonne] et [updatePersonne] selon qu'on doit
faire un ajout ou une modification de personne.
ligne 50 : la mthode prive [check] est celle de la version prcdente. Nous ne reviendrons pas dessus.
ligne 8 : pour implmenter linterface [IDao], la classe [DaoImpl] drive de la classe Spring [SqlMapClientDaoSupport].
2.3.2
// vrification validit d'une personne

private void check(Personne p) {
...
}
...
}
La couche daccs aux donnes [iBATIS]
La classe Spring [SqlMapClientDaoSupport] utilise un framework tierce [Ibatis SqlMap] disponible lurl [http://ibatis.apache.org/]
:
[iBATIS] est un projet Apache qui facilite la construction de couches [dao] sappuyant sur des bases de donnes. Avec [iBATIS],
l'architecture de la couche d'accs aux donnes est la suivante :
utilisateur
Couche d'accs
aux donnes
[dao]
Couche d'accs
aux donnes
[iBATIS]
Couche d'accs
aux donnes
[JDBC]
Donnes
[iBATIS] s'insre entre la couche [dao] de l'application et le pilote JDBC de la base de donnes. Il existe des alternatives [iBATIS]
telle, par exemple, l'alternative [Hibernate] :
8/73
utilisateur
Couche d'accs
aux donnes
[dao]
Couche d'accs
aux donnes
[Hibernate]
Couche d'accs
aux donnes
[JDBC]
Donnes
Lutilisation du framework [iBATIS] ncessite deux archives [ibatis-common, ibatis-sqlmap] qui ont t toutes deux places dans le
dossier [lib] du projet :
La classe [SqlMapClientDaoSupport] encapsule la partie gnrique de lutilisation du framework [iBATIS], c.a.d. des parties de code
quon retrouve dans toutes les couche [dao] utilisant l'outil [iBATIS]. Pour crire la partie non gnrique du code, cest dire ce qui
est spcifique la couche [dao] que lon crit, il suffit de driver la classe [SqlMapClientDaoSupport]. Cest ce que nous faisons ici.
La classe [SqlMapClientDaoSupport] est dfinie comme suit :
Parmi les mthodes de cette classe, lune delles permet de configurer le client [iBATIS] avec lequel on va exploiter la base de
donnes :
Lobjet [SqlMapClient sqlMapClient] est lobjet [IBATIS] utilis pour accder une base de donnes. A lui tout seul, il implmente
la couche [iBATIS] de notre architecture :
9/73
utilisateur
Couche d'accs aux donnes

[SqlMapDaoClientSupport :
DaoImplCommon]

[SqlMapClient]
Couche d'accs
aux donnes
[JDBC]
Donnes
Une squence typique dactions avec cet objet est la suivante :

1.
2.
3.
4.
5.
demander une connexion un pool de connexions

ouvrir une transaction
excuter une srie dordres SQL mmorise dans un fichier de configuration
fermer la transaction
rendre la connexion au pool
Si notre implmentation [DaoImplCommon] travaillait directement avec [iBATIS], elle devrait faire cette squence de faon
rpte. Seule lopration 3 est spcifique une couche [dao], les autres oprations tant gnriques. La classe Spring
[SqlMapClientDaoSupport] assurera elle-mme les oprations 1, 2, 4 et 5, dlguant lopration 3 sa classe drive, ici la classe
[DaoImplCommon].
Pour pouvoir fonctionner, la classe [SqlMapClientDaoSupport] a besoin dune rfrence sur lobjet iBATIS [SqlMapClient
sqlMapClient] qui va assurer le dialogue avec la base de donnes. Cet objet a besoin de deux choses pour fonctionner :
un objet [DataSource] connect la base de donnes auprs duquel il va demander des connexions
un (ou des) fichier de configuration o sont externaliss les ordres SQL excuter. En effet, ceux-ci ne sont pas dans le
code Java. Ils sont identifis par un code dans un fichier de configuration et lobjet [SqlMapClient sqlMapClient] utilise ce
code pour faire excuter un ordre SQL particulier.
Un embryon de configuration de notre couche [dao] qui reflterait l'architecture ci-dessus serait le suivant :
1. 
2. <bean id="dao" class="istia.st.springmvc.personnes.dao.DaoImplCommon">
3.
<property name="sqlMapClient">
4.
<ref local="sqlMapClient"/>
5.
</property>
6.</bean>
Ici la proprit [sqlMapClient] (ligne 3) de la classe [DaoImplCommon] (ligne 2) est initialise. Elle lest par la mthode
[setSqlMapClient] de la classe [DaoImpl]. Cette classe na pas cette mthode. Cest sa classe parent [SqlMapClientDaoSupport] qui
la. Cest donc elle qui est en ralit initialise ici.
Maintenant ligne 4, on fait rfrence un objet nomm " sqlMapClient " qui reste construire. Celui-ci, on la dit, est de type
[SqlMapClient], un type [iBATIS] :
[SqlMapClient] est une interface. Spring offre la classe [SqlMapClientFactoryBean] pour obtenir un objet implmentant cette
interface :
Rappelons que nous cherchons instancier un objet implmentant linterface [SqlMapClient]. Ce nest apparemment pas le cas de la
classe [SqlMapClientFactoryBean]. Celle-ci implmente linterface [FactoryBean] (cf ci-dessus). Celle-ci a la mthode [getObject()]
suivante :
10/73
Lorsquon demande Spring une instance dun objet implmentant linterface [FactoryBean], il :
cre une instance [I] de la classe - ici il cre une instance de type [SqlMapClientFactoryBean].
rend la mthode appelante, le rsultat de la mthode [I].getObject() - la mthode [SqlMapClientFactoryBean].getObject()
va rendre ici un objet implmentant linterface [SqlMapClient].
Pour pouvoir rendre un objet implmentant linterface [SqlMapClient], la classe [SqlMapClientFactoryBean] a besoin de deux
informations ncessaires cet objet :
un objet [DataSource] connect la base de donnes auprs duquel il va demander des connexions
un (ou des) fichier de configuration o sont externaliss les ordres SQL excuter
La classe [SqlMapClientFactoryBean] possde les mthodes set pour initialiser ces deux proprits :
Nous progressons... Notre fichier de configuration se prcise et devient :

1.
2. <bean id="sqlMapClient"
3.
class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
4.
<property name="dataSource">
5.
<ref local="dataSource"/>
6.
</property>
7.
<property name="configLocation">
8.
<value>classpath:sql-map-config-firebird.xml</value>
9.
</property>
10. </bean>
13. <property name="sqlMapClient">
14.
15. </property>
16. </bean>
lignes 2-3 : le bean " sqlMapClient " est de type [SqlMapClientFactoryBean]. De ce qui vient dtre expliqu, nous savons
que lorsque nous demandons Spring une instance de ce bean, nous obtenons un objet implmentant linterface iBATIS
[SqlMapClient]. Cest ce dernier objet qui sera donc obtenu en ligne 14.
lignes 7-9 : nous indiquons que le fichier de configuration ncessaire lobjet iBATIS [SqlMapClient] sappelle " sql-mapconfig-firebird.xml " et quil doit tre cherch dans le ClassPath de lapplication. La mthode
[SqlMapClientFactoryBean].setConfigLocation est ici utilise.
lignes 4-6 : nous initialisons la proprit [dataSource] de [SqlMapClientFactoryBean] avec sa mthode [setDataSource].
Ligne 5, nous faisons rfrence un bean appel " dataSource " qui reste construire. Si on regarde le paramtre attendu par la
mthode [setDataSource] de [SqlMapClientFactoryBean], on voit quil est de type [DataSource] :
On a de nouveau affaire une interface dont il nous faut trouver une classe dimplmentation. Le rle dune telle classe est de
fournir une application, de faon efficace, des connexions une base de donnes particulire. Un SGBD ne peut maintenir
ouvertes simultanment un grand nombre de connexions. Pour diminuer le nombre de connexions ouvertes un moment donn,
on est amens, pour chaque change avec la base, :
ouvrir une connexion

commencer une transaction
mettre des ordres SQL
fermer la transaction
fermer la connexion
Ouvrir et fermer des connexions de faon rpte est coteux en temps. Pour rsoudre ces deux problmes (limiter la fois le
nombre de connexions ouvertes un moment donn, et limiter le cot douverture / fermeture de celles-ci, les classes
implmentant linterface [DataSource] procdent souvent de la faon suivante :
11/73
elles ouvrent ds leur instanciation, N connexions avec la base de donnes vise. N a en gnral une valeur par dfaut et
peut le plus souvent tre dfini dans un fichier de configuration. Ces N connexions vont rester tout le temps ouvertes et
forment un pool de connexions disponibles pour les threads de lapplication.
lorsquun thread de lapplication demande une ouverture de connexion, lobjet [DataSource] lui donne lune des N
connexions ouvertes au dmarrage, sil en reste de disponibles. Lorsque lapplication ferme la connexion, cette dernire
nest en ralit pas ferme mais simplement remise dans le pool des connexions disponibles.
Il existe diverses implmentations de linterface [DataSource] disponibles librement. Nous allons utiliser ici limplmentation
[commons DBCP] disponible lurl [http://jakarta.apache.org/commons/dbcp/] :
Lutilisation de loutil [commons DBCP] ncessite deux archives [commons-dbcp, commons-pool] qui ont t toutes deux places
dans le dossier [lib] du projet :
La classe [BasicDataSource] de [commons DBCP] fournit limplmentation [DataSource] dont nous avons besoin :
Cette classe va nous fournir un pool de connexions pour accder la base Firebird [dbpersonnes.gdb] de notre application. Pour
cela, il faut lui donner les informations dont elle a besoin pour crer les connexions du pool :
1.
2.
3.
4.
le nom du pilote JDBC utiliser initialis avec [setDriverClassName]

le nom de lurl de la base de donnes exploiter - initialis avec [setUrl]
lidentifiant de lutilisateur propritaire de la connexion initialis avec [setUsername] (et non pas setUserName comme
on aurait pu s'y attendre)
son mot de passe - initialis avec [setPassword]
Le fichier de configuration de notre couche [dao] pourra tre le suivant :

1. <?xml version="1.0" encoding="ISO_8859-1"?>
2. <!DOCTYPE beans SYSTEM "http://www.springframework.org/dtd/spring-beans.dtd">
3. <beans>
4.

5.
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
6.
destroy-method="close">
7.
<property name="driverClassName">
8.
<value>org.firebirdsql.jdbc.FBDriver</value>
9.
</property>
10.

11.
<property name="url">
12.
<value>jdbc:firebirdsql:localhost/3050:C:/data/2005-2006/webjava/dvp-spring-mvc/mvc38/database/dbpersonnes.gdb</value>
13.
</property>
14.
<property name="username">
15.
<value>sysdba</value>
12/73
16.
</property>
17.
<property name="password">
18.
<value>masterkey</value>
19.
</property>
20. </bean>
21. 
23.
24.
25.
26.
</property>
27.
28.
29.
</property>
30. </bean>
33.
34.
35.
</property>
36. </bean>
37. </beans>
lignes 7-9 : le nom du pilote JDBC du SGBD Firebird

lignes 11-13 : lurl de la base Firebird [dbpersonnes.gdb]. On fera particulirement attention lcriture de celle-ci. Il ne
doit y avoir aucun espace entre les balises <value> et lurl.
lignes 14-16 : le propritaire de la connexion ici, [sysdba] qui est ladministrateur par dfaut des distributions Firebird
lignes 17-19 : son mot de passe [masterkey] galement la valeur par dfaut
On a beaucoup progress mais il reste toujours des points de configuration lucider : la ligne 28 rfrence le fichier [sql-mapconfig-firebird.xml] qui doit configurer le client [SqlMapClient] diBATIS. Avant dtudier son contenu, montrons lemplacement de
ces fichiers de configuration dans notre projet Eclipse :
[spring-config-test-dao-firebird.xml] est le fichier de configuration de la couche [dao] que nous venons dtudier
[sql-map-config-firebird.xml] est rfrenc par [spring-config-test-dao-firebird.xml]. Nous allons ltudier.
[personnes-firebird.xml] est rfrenc par [sql-map-config-firebird.xml]. Nous allons ltudier.
Les trois fichiers prcdents sont dans le dossier [src]. Sous Eclipse, cela signifie qu lexcution ils seront prsents dans le dossier
[bin] du projet (non reprsent ci-dessus). Ce dossier fait partie du ClassPath de lapplication. Au final, les trois fichiers prcdents
seront donc bien prsents dans le ClassPath de lapplication. Cest ncessaire.
Le fichier [sql-map-config-firebird.xml] est le suivant :
1.
2.
3.
4.
5.
6.
7.
8.
<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE sqlMapConfig
PUBLIC "-//iBATIS.com//DTD SQL Map Config 2.0//EN"
"http://www.ibatis.com/dtd/sql-map-config-2.dtd">
ce fichier doit avoir <sqlMapConfig> comme balise racine (lignes 6 et 8)

ligne 7 : la balise <sqlMap> sert dsigner les fichiers qui contiennent les ordres SQL excuter. Il y a souvent, mais ce
nest pas obligatoire, un fichier par table. Cela permet de rassembler les ordres SQL sur une table donne dans un mme
fichier. Mais on trouve frquemment des ordres SQL impliquant plusieurs tables. Dans ce cas, la dcomposition
prcdente ne tient pas. Il faut simplement se rappeler que lensemble des fichiers dsigns par les balises <sqlMap>
seront fusionns. Ces fichiers sont cherchs dans le ClassPath de lapplication.
<sqlMapConfig>
<sqlMap resource="personnes-firebird.xml"/>
</sqlMapConfig>
Le fichier [personnes-firebird.xml] dcrit les ordres SQL qui vont tre mis sur la table [PERSONNES] de la base de donnes
Firebird [dbpersonnes.gdb]. Son contenu est le suivant :
1.
2.
13/73
3. <!DOCTYPE sqlMap
4.
PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"
5.
"http://www.ibatis.com/dtd/sql-map-2.dtd">
6.
7. <sqlMap>
8.

9.
<typeAlias alias="Personne.classe"
10.
type="istia.st.springmvc.personnes.entites.Personne"/>
11. 
12. <resultMap id="Personne.map"
13.
class="Personne.classe">
14.
<result property="id" column="ID" />
15.
<result property="version" column="VERSION" />
16.
<result property="nom" column="NOM"/>
17.
<result property="prenom" column="PRENOM"/>
18.
<result property="dateNaissance" column="DATENAISSANCE"/>
19.
<result property="marie" column="MARIE"/>
20.
<result property="nbEnfants" column="NBENFANTS"/>
21. </resultMap>
22. 
23. <select id="Personne.getAll" resultMap="Personne.map" > select ID, VERSION, NOM,
24.
PRENOM, DATENAISSANCE, MARIE, NBENFANTS FROM PERSONNES</select>
25. 
26.
<select id="Personne.getOne" resultMap="Personne.map" >select ID, VERSION, NOM,
27.
PRENOM, DATENAISSANCE, MARIE, NBENFANTS FROM PERSONNES WHERE ID=#value#</select>
28. 
29. <insert id="Personne.insertOne" parameterClass="Personne.classe">
30.
<selectKey keyProperty="id">
31.
SELECT GEN_ID(GEN_PERSONNES_ID,1) as "value" FROM RDB$$DATABASE
32.
</selectKey>
33.
insert into
34.
PERSONNES(ID, VERSION, NOM, PRENOM, DATENAISSANCE, MARIE, NBENFANTS)
35.
VALUES(#id#, #version#, #nom#, #prenom#, #dateNaissance#, #marie#,
36.
#nbEnfants#) </insert>
37. 
38. <update id="Personne.updateOne" parameterClass="Personne.classe"> update
39.
PERSONNES set VERSION=#version#+1, NOM=#nom#, PRENOM=#prenom#, DATENAISSANCE=#dateNaissance#,
40.
MARIE=#marie#, NBENFANTS=#nbEnfants# WHERE ID=#id# and
41.
VERSION=#version#</update>
42. 
43. <delete id="Personne.deleteOne" parameterClass="int"> delete FROM PERSONNES WHERE
44.
ID=#value# </delete>
45. </sqlMap>
le fichier doit avoir <sqlMap> comme balise racine (lignes 7 et 45)

lignes 9-10 : pour faciliter lcriture du fichier on donne lalias (synonyme) [Personne.classe] la classe
[istia.st.springmvc.personnes.entites.Personne].
lignes 12-21 : fixe les correspondances entre colonnes de la table [PERSONNES] et champs de lobjet [Personne].
lignes 23-24 : lordre SQL [select] pour obtenir toutes les personnes de la table [PERSONNES]
lignes 26-27 : lordre SQL [select] pour obtenir une personne particulire de la table [PERSONNES]
lignes 29-36 : lordre SQL [insert] qui insre une personne dans la table [PERSONNES]
lignes 38-41 : lordre SQL [update] qui met jour une personne de la table [PERSONNES]
lignes 42-44 : lordre SQL [delete] qui supprime une personne de la table [PERSONNES]
Le rle et la signification du contenu du fichier [personnes-firebird.xml] vont tre expliqus via ltude de la classe
[DaoImplCommon] qui implmente la couche [dao]
2.3.3
La classe [DaoImplCommon]
Revenons sur larchitecture daccs aux donnes :

utilisateur

[SqlMapDaoClientSupport :
DaoImplCommon]

[SqlMapClient]
Couche d'accs
aux donnes
[JDBC]
Donnes
La classe [DaoImplCommon] est la suivante :

1. package istia.st.springmvc.personnes.dao;
2.
3. import istia.st.springmvc.personnes.entites.Personne;
4. import org.springframework.orm.ibatis.support.SqlMapClientDaoSupport;
5.
6. import java.util.Collection;
14/73
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
public class DaoImplCommon extends SqlMapClientDaoSupport implements

IDao {
public Collection getAll() {
...
}
public Personne getOne(int id) {
...
}
// suppression d'une personne
public void deleteOne(int id) {
...
}
public void saveOne(Personne personne) {
check(personne);
// ajout
} else {
}
}
// ajouter une personne
protected void insertPersonne(Personne personne) {
...
}
...
}
// vrification validit d'une personne
private void check(Personne p) {
...
}
...
}
Nous allons tudier les mthodes les unes aprs les autres.
getAll
Cette mthode permet dobtenir toutes les personnes de la liste. Son code est le suivant :
1. // liste des personnes
2. public Collection getAll() {
3.
return getSqlMapClientTemplate().queryForList("Personne.getAll", null);
4.}
Rappelons-nous tout dabord que la classe [DaoImplCommon] drive de la classe Spring [SqlMapClientDaoSupport]. Cest cette
classe qui a la mthode [getSqlMapClientTemplate()] utilise ligne 3 ci-dessus. Cette mthode a la signature suivante :
Le type [SqlMapClientTemplate] encapsule lobjet [SqlMapClient] de la couche [iBATIS]. Cest par lui quon aura accs la base de
donnes. Le type [iBATIS] SqlMapClient pourrait tre directement utilis puisque la classe [SqlMapClientDaoSupport] y a accs :
Linconvnient de la classe [iBATIS] SqlMapClient est quelle lance des exceptions de type [SQLException], un type d'exception
contrle, c.a.d. qui doit tre gre par un try / catch ou dclare dans la signature des mthodes qui la lance. Or souvenons-nous
que la couche [dao] implmente une interface [IDao] dont les mthodes ne comportent pas dexceptions dans leurs signatures. Les
15/73
mthodes des classes dimplmentation de linterface [IDao] ne peuvent donc, elles non plus, avoir dexceptions dans leurs
signatures. Il nous faut donc intercepter chaque exception [SQLException] lance par la couche [iBATIS] et lencapsuler dans une
exception non contrle. Le type [DaoException] de notre projet ferait laffaire pour cette encapsulation.
Plutt que de grer nous-mmes ces exceptions, nous allons les confier au type Spring [SqlMapClientTemplate] qui encapsule
lobjet [SqlMapClient] de la couche [iBATIS]. En effet [SqlMapClientTemplate] a t construit pour intercepter les exceptions
[SQLException] lances par la couche [SqlMapClient] et les encapsuler dans un type [DataAccessException] non contrl. Ce
comportement nous convient. On se souviendra simplement que la couche [dao] est dsormais susceptible de lancer deux types
dexceptions non contrles :
notre type propritaire [DaoException]
le type Spring [DataAccessException]

Le type [SqlMapClientTemplate] est dfini comme suit :
Il implmente linterface [SqlMapClientOperations] suivante :
Cette interface dfinit des mthodes capables dexploiter le contenu du fichier [personnes-firebird.xml] :
[queryForList]
Cette mthode permet dmettre un ordre [SELECT] et den rcuprer le rsultat sous forme dune liste dobjets :
[statementName] : lidentifiant (id) de lordre [select] dans le fichier de configuration

[parameterObject] : lobjet " paramtre " pour un [select] paramtr. Lobjet " paramtre " peut prendre deux formes :
un objet respectant la norme Javabean : les paramtres de lordre [select] sont alors les noms des champs du
Javabean. A lexcution de lordre [select], ils sont remplacs par les valeurs de ces champs.
un dictionnaire : les paramtres de lordre [select] sont alors les cls du dictionnaire. A lexcution de lordre
[select], celles-ci sont remplaces par leurs valeurs associes dans le dictionnaire.
si le [SELECT] ne ramne aucune ligne, le rsultat [List] est un objet vide d'lments mais pas null ( vrifier).
[queryForObject]
Cette mthode est identique dans son esprit la prcdente mais elle ne ramne quun unique objet. Si le [SELECT] ne ramne
aucune ligne, le rsultat est le pointeur null.
[insert]
Cette mthode permet dexcuter un ordre SQL [insert] paramtr par le second paramtre. L'objet rendu est la cl primaire de la
ligne qui a t insre. Il n'y a pas d'obligation utiliser ce rsultat.
16/73
[update]
Cette mthode permet dexcuter un ordre SQL [update] paramtr par le second paramtre. Le rsultat est le nombre de lignes
modifies par l'ordre SQL [update].
[delete]
Cette mthode permet dexcuter un ordre SQL [delete] paramtr par le second paramtre. Le rsultat est le nombre de lignes
supprimes par l'ordre SQL [delete].
Revenons la mthode [getAll] de la classe [DaoImplCommon] :
3.
return getSqlMapClientTemplate().queryForList("Personne.getAll", null);
4.}
ligne 4 : lordre [select] nomm " Personne.getAll " est excut. Il nest pas paramtr et donc lobjet " paramtre " est null.
Dans [personnes-firebird.xml], lordre [select] nomm " Personne.getAll " est le suivant :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
ligne 23 : lordre SQL " Personne.getAll " est non paramtr (absence de paramtres dans le texte de la requte).
la ligne 3 de la mthode [getAll] demande lexcution de la requte [select] appele " Personne.getAll ". Celle-ci va tre
excute. [iBATIS] sappuie sur JDBC. On sait alors que le rsultat de la requte va tre obtenu sous la forme dun objet
[ResultSet]. Ligne 23, lattribut [resultMap] de la balise <select> indique [iBATIS] quel " resultMap " il doit utiliser pour
transformer chaque ligne du [ResultSet] obtenu en objet. Cest le " resultMap " [Personne.map] dfini lignes 12-21 qui
indique comment passer dune ligne de la table [PERSONNES] un objet de type [Personne]. [iBATIS] va utiliser ces
correspondances pour fournir une liste dobjets [Personne] partir des lignes de lobjet [ResultSet].
la ligne 3 de la mthode [getAll] renvoie alors une collection dobjets [Personne]
la mthode [queryForList] peut lancer une exception Spring [DataAccessException]. Nous la laissons remonter.
<!DOCTYPE sqlMap
<sqlMap>

<resultMap id="Personne.map"
class="Personne.classe">
</resultMap>

<select id="Personne.getAll" resultMap="Personne.map" > select ID, VERSION, NOM,
...
</sqlMap>
Nous expliquons les autres mthodes de la classe [AbstractDaoImpl] plus rapidement, lessentiel sur lutilisation d[iBATIS] ayant
t dit dans ltude de la mthode [getAll].
getOne
Cette mthode permet dobtenir une personne identifie par son [id]. Son code est le suivant :
17/73
1.
2. public Personne getOne(int id) {
3.
// on la rcupre dans la BD
4.
Personne personne = (Personne) getSqlMapClientTemplate()
5.
.queryForObject("Personne.getOne", new Integer(id));
6.
// a-t-on rcupr qq chose ?
7.
if (personne == null) {
8.
// on lance une exception
9.
throw new DaoException(
10.
"La personne d'id [" + id + "] n'existe pas", 2);
11. }
12. // on rend la personne
13. return personne;
14. }
ligne 4 : demande lexcution de lordre [select] nomm " Personne.getOne ". Celui-ci est le suivant dans le fichier
[personnes-firebird.xml] :
1. 
2.
<select id="Personne.getOne" resultMap="Personne.map" parameterClass="int">
3.
select ID, VERSION, NOM, PRENOM, DATENAISSANCE, MARIE, NBENFANTS FROM
4.
PERSONNES WHERE ID=#value#</select>
Lordre SQL est paramtr par le paramtre #value# (ligne 4). Lattribut #value# dsigne la valeur du paramtre pass
lordre SQL, lorsque ce paramtre est de type simple : Integer, Double, String, ... Dans les attributs de la balise <select>,
lattribut [parameterClass] indique que le paramtre est de type entier (ligne 2). Ligne 5 de [getOne], on voit que ce
paramtre est lidentifiant de la personne cherche sous la forme dun objet Integer. Ce changement de type est obligatoire
puisque le second paramtre de [queryForList] doit tre de type [Object].
Le rsultat de la requte [select] sera transformer en objet via lattribut [resultMap="Personne.map"] (ligne 2). On
obtiendra donc un type [Personne].
lignes 7-11 : si la requte [select] na ramen aucune ligne, on rcupre alors le pointeur null en ligne 4. Cela signifie quon
na pas trouv la personne cherche. Dans ce cas, on lance une [DaoException] de code 2 (lignes 9-10).
ligne 13 : sil ny a pas eu dexception, alors on rend lobjet [Personne] demand.
deleteOne
Cette mthode permet de supprimer une personne identifie par son [id]. Son code est le suivant :
1. // suppression d'une personne
2. public void deleteOne(int id) {
3.
// on supprime la personne
4.
int n = getSqlMapClientTemplate().delete("Personne.deleteOne",
5.
new Integer(id));
6.
// a-t-on russi
7.
if (n == 0) {
8.
throw new DaoException("Personne d'id [" + id + "] inconnue", 2);
9.
}
10. }
lignes 4-5 : demande lexcution de lordre [delete] nomm " Personne.deleteOne ". Celui-ci est le suivant dans le fichier
[personnes-firebird.xml] :
1.
2. <delete id="Personne.deleteOne" parameterClass="int"> delete FROM PERSONNES WHERE
3.
Lordre SQL est paramtr par le paramtre #value# (ligne 3) de type [parameterClass="int"] (ligne 2). Ce sera
lidentifiant de la personne cherche (ligne 5 de deleteOne)
ligne 4 : le rsultat de la mthode [SqlMapClientTemplate].delete est le nombre de lignes dtruites.

lignes 7-8 : si la requte [delete] na dtruit aucune ligne, cela signifie que la personne nexiste pas. On lance une
[DaoException] de code 2 (ligne 8).
saveOne
Cette mthode permet dajouter une nouvelle personne ou de modifier une personne existante. Son code est le suivant :
1.
2. public void saveOne(Personne personne) {
3.
18/73
4.
check(personne);
5.
6.
7.
// ajout
8.
9.
} else {
10.
11. }
12. }
13....
ligne 4 : on vrifie la validit de la personne avec la mthode [check]. Cette mthode existait dj dans la version
prcdente et avait t alors commente. Elle lance une [DaoException] si la personne est invalide. On laisse remonter
celle-ci.
ligne 6 : si on arrive l, cest quil ny a pas eu dexception. La personne est donc valide.
lignes 6-11 : selon lid de la personne, on a affaire un ajout (id= -1) ou une mise jour (id<> -1). Dans les deux cas, on
fait appel deux mthodes internes la classe :
insertPersonne : pour lajout
updatePersonne : pour la mise jour
insertPersonne
Cette mthode permet dajouter une nouvelle personne. Son code est le suivant :
1.// ajouter une personne
2. protected void insertPersonne(Personne personne) {
3.
// 1re version
4.
personne.setVersion(1);
5.
// on attend 10 ms - pour les tests mettre true au lieu de false
6.
if (true)
7.
wait(10);
8.
// on insre la nouvelle personne dans la table de la BD
9.
getSqlMapClientTemplate().insert("Personne.insertOne", personne);
10. }
ligne 4 : on met 1 le n de version de la personne que lon est en train de crer

ligne 9 : on fait linsertion via la requte nomme " Personne.insertOne " qui est la suivante :
1.
2.
3.
4.
5.
6.
7.
8.
<insert id="Personne.insertOne" parameterClass="Personne.classe">

SELECT GEN_ID(GEN_PERSONNES_ID,1) as "value" FROM RDB$$DATABASE
</selectKey>
insert into
PERSONNES(ID, VERSION, NOM, PRENOM, DATENAISSANCE, MARIE, NBENFANTS)
VALUES(#id#, #version#, #nom#, #prenom#, #dateNaissance#, #marie#,
#nbEnfants#) </insert>
Cest une requte paramtre et le paramtre est de type [Personne] (parameterClass="Personne.classe", ligne 1). Les
champs de lobjet [Personne] passs en paramtre (ligne 9 de insertPersonne) sont utiliss pour remplir les colonnes de la
ligne qui va tre insre dans la table [PERSONNES] (lignes 5-8). On a un problme rsoudre. Lors d'une insertion,
lobjet [Personne] insrer a son id gal -1. Il faut remplacer cette valeur par une cl primaire valide. On utilise pour cela
les lignes 2-4 de la balise <selectKey> ci-dessus. Elles indiquent :
la requte SQL excuter pour obtenir une valeur de cl primaire. Celle indique ici est celle que nous avons
prsente au paragraphe 2.1 - page 4. Deux points sont noter :
as " value " est obligatoire. On peut aussi crire as value mais value est un mot cl de Firebird qui a du
tre protg par des guillemets.
la table Firebird s'appelle en ralit [RDB$DATABASE]. Mais le caractre $ est interprt par [iBATIS].
Il a t protg en le ddoublant.
le champ de l'objet [Personne] qu'il faut initialiser avec la valeur rcupre par l'ordre [SELECT], ici le champ
[id]. C'est l'attribut [keyProperty] de la ligne 2 qui indique ce champ.
lignes 6-7 : pour le besoin des tests, nous serons amens attendre 10 ms avant de faire l'insertion, ceci pour voir sil y a
des conflits entre threads qui voudraient faire en mme temps des ajouts.
updatePersonne
Cette mthode permet de modifier une personne existant dj dans la table [PERSONNES]. Son code est le suivant :
1.// modifier une personne
2. protected void updatePersonne(Personne personne) {
3.
4.
if (true)
19/73
5.
wait(10);
6.
// modification
7.
int n = getSqlMapClientTemplate()
8.
.update("Personne.updateOne", personne);
9.
if (n == 0)
10.
throw new DaoException("La personne d'Id [" + personne.getId()
11.
+ "] n'existe pas ou bien a t modifie", 2);
12. }
une mise jour peut chouer pour au moins deux raisons :

1. la personne mettre jour nexiste pas
2. la personne mettre jour existe mais le thread qui veut la modifier na pas la bonne version
lignes 7-8 : la requte SQL [update] nomme " Personne.updateOne " est excute. C'est la suivante :
1.
2.
3.


<update id="Personne.updateOne" parameterClass="Personne.classe"> update
PERSONNES set VERSION=#version#+1, NOM=#nom#, PRENOM=#prenom#,
DATENAISSANCE=#dateNaissance#,
4.
5. VERSION=#version#</update>
2.4
2.4.1
ligne 2 : la requte est paramtre et admet pour paramtre un type [Personne]

(parameterClass="Personne.classe"). Celui-ci est la personne modifier (ligne 8 updatePersonne).
on ne veut modifier que la personne de la table [PERSONNES] ayant le mme n [id] et la mme version
[version] que le paramtre. Cest pourquoi, on a la contrainte [WHERE ID=#id# and VERSION=#version#].
Si cette personne est trouve, elle est mise jour avec la personne paramtre et sa version est augmente de 1
(ligne 3 ci-dessus).
ligne 9 : on rcupre le nombre de lignes mises jour.

lignes 10-11 : si ce nombre est nul, on lance une [DaoException] de code 2, indiquant que, soit la personne mettre jour
nexiste pas, soit elle a chang de version entre-temps.
Tests de la couche [dao]

Tests de l'implmentation [DaoImplCommon]
Maintenant que nous avons crit la couche [dao], nous nous proposons de la tester avec des tests JUnit :
Avant de faire des tests intensifs, nous pouvons commencer par un simple programme de type [main] qui va afficher le contenu de
la table [PERSONNES]. Cest la classe [MainTestDaoFirebird] :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
package istia.st.springmvc.personnes.tests;
import istia.st.springmvc.personnes.dao.IDao;
import java.util.Iterator;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.ClassPathResource;
public class MainTestDaoFirebird {
public static void main(String[] args) {
IDao dao = (IDao) (new XmlBeanFactory(new ClassPathResource(
"spring-config-test-dao-firebird.xml"))).getBean("dao");
// liste actuelle
Collection personnes = dao.getAll();
// affichage console
Iterator iter = personnes.iterator();
while (iter.hasNext()) {
System.out.println(iter.next());
}
20/73
22. }
23. }
Le fichier de configuration [spring-config-test-dao-firebird.xml] de la couche [dao], utilis lignes 13-14, est le suivant :
3. <beans>
4.
5.
6.
7.
8.
9.
</property>
10.

11.
12.
13.
</property>
14.
15.
16.
</property>
17.
18.
19.
</property>
20. </bean>
23.
24.
25.
26.
</property>
27.
28.
29.
</property>
30. </bean>
33.
34.
35.
</property>
36. </bean>
37. </beans>
Ce fichier est celui tudi au paragraphe 2.3.2, page 12.

Pour le test, le SGBD Firebird est lanc. Le contenu de la table [PERSONNES] est le suivant :
Lexcution du programme [MainTestDaoFirebird] donne les rsultats cran suivants :
On a bien obtenu la liste des personnes. On peut passer au test JUnit.

Le test JUnit [TestDaoFirebird] est le suivant :
1.
2.
3.
4.
5.
import java.text.ParseException;
import java.text.SimpleDateFormat;
21/73
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
import java.util.Iterator;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.ClassPathResource;
les tests [test1] [test5] sont les mmes que dans la version 1, sauf [test4] qui a lgrement volu. Le test [test6] est lui
nouveau. Nous ne commentons que ces deux tests.
import
import
import
import
istia.st.springmvc.personnes.dao.DaoException;
istia.st.springmvc.personnes.dao.IDao;
istia.st.springmvc.personnes.entites.Personne;
junit.framework.TestCase;
public class TestDaoFirebird extends TestCase {

// couche [dao]
private IDao dao;
public IDao getDao() {
return dao;
}
public void setDao(IDao dao) {
this.dao = dao;
}
// constructeur
public void setUp() {
dao = (IDao) (new XmlBeanFactory(new ClassPathResource(
"spring-config-test-dao-firebird.xml"))).getBean("dao");
}
private void doListe(Collection personnes) {
...
}
// test1
public void test1() throws ParseException {
...
}
// modification-suppression d'un lment inexistant
..
}
// gestion des versions de personne
public void test3() throws ParseException, InterruptedException {
...
}
// optimistic locking - accs multi-threads
public void test4() throws Exception {
...
}
// tests de validit de saveOne
....
}
// insertions multi-threads
public void test6() throws ParseException, InterruptedException{
...
}
[test4]
[test4] a pour objectif de tester la mthode [updatePersonne - DaoImplCommon]. On rappelle le code de celle-ci :
1.// modifier une personne
2. protected void updatePersonne(Personne personne) {
3.
4.
if (true)
5.
wait(10);
6.
// modification
7.
8.
9.
if (n == 0)
10.
11.
12. }
22/73
lignes 4-5 : on attend 10 ms. On force ainsi le thread qui excute [updatePersonne] perdre le processeur, ce qui peut
augmenter nos chances de voir des conflits daccs entre threads concurrents.
[test4] lance N=100 threads chargs dincrmenter, en mme temps, de 1 le nombre denfants de la mme personne. On veut voir
comment les conflits de version et les conflits daccs sont grs.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.

// ajout d'une personne
Personne p1 = new Personne(-1, "X", "X", new SimpleDateFormat(
"dd/MM/yyyy").parse("01/02/2006"), true, 0);
dao.saveOne(p1);
int id1 = p1.getId();
// cration de N threads de mise jour du nombre d'enfants
final int N = 100;
Thread[] taches = new Thread[N];
for (int i = 0; i < taches.length; i++) {
taches[i] = new ThreadDaoMajEnfants("thread n " + i, dao, id1);
taches[i].start();
}
// on attend la fin des threads
taches[i].join();
}
// on rcupre la personne
p1 = dao.getOne(id1);
// elle doit avoir N enfants
assertEquals(N, p1.getNbEnfants());
// suppression personne p1
dao.deleteOne(p1.getId());
// vrification
boolean erreur = false;
int codeErreur = 0;
try {
p1 = dao.getOne(p1.getId());
} catch (DaoException ex) {
erreur = true;
codeErreur = ex.getCode();
}
// on doit avoir une erreur de code 2
assertTrue(erreur);
assertEquals(2, codeErreur);
}
Les threads sont crs lignes 8-13. Chacun va augmenter de 1 le nombre d'enfants de la personne cre lignes 3-5. Les threads
[ThreadDaoMajEnfants ] de mise jour sont les suivants :
1. package istia.st.springmvc.personnes.tests;
2.
3. import java.util.Date;
4.
5. import istia.st.springmvc.personnes.dao.DaoException;
6. import istia.st.springmvc.personnes.dao.IDao;
8.
9. public class ThreadDaoMajEnfants extends Thread {
10. // nom du thread
11. private String name;
12.
13. // rfrence sur la couche [dao]
14. private IDao dao;
15.
16. // l'id de la personne sur qui on va travailler
17. private int idPersonne;
18.
19. // constructeur
20. public ThreadDaoMajEnfants(String name, IDao dao, int idPersonne) {
21.
this.name = name;
22.
this.dao = dao;
23.
this.idPersonne = idPersonne;
24. }
25.
26. // coeur du thread
27. public void run() {
28.
// suivi
29.
suivi("lanc");
30.
// on boucle tant qu'on n'a pas russi incrmenter de 1
31.
// le nbre d'enfants de la personne idPersonne
32.
boolean fini = false;
33.
int nbEnfants = 0;
34.
while (!fini) {
35.
// on rcupre une copie de la personne d'idPersonne
36.
Personne personne = dao.getOne(idPersonne);
37.
nbEnfants = personne.getNbEnfants();
23/73
38.
// suivi
39.
suivi("" + nbEnfants + " -> " + (nbEnfants + 1)
40.
+ " pour la version " + personne.getVersion());
41.
// attente de 10 ms pour abandonner le processeur
42.
try {
43.
// suivi
44.
suivi("dbut attente");
45.
// on s'interrompt pour laisser le processeur
46.
Thread.sleep(10);
47.
// suivi
48.
suivi("fin attente");
49.
} catch (Exception ex) {
50.
throw new RuntimeException(ex.toString());
51.
}
52.
// attente termine - on essaie de valider la copie
53.
// entre-temps d'autres threads ont pu modifier l'original
54.
int codeErreur = 0;
55.
try {
56.
// incrmente de 1 le nbre d'enfants de cette copie
57.
personne.setNbEnfants(nbEnfants + 1);
58.
// on essaie de modifier l'original
59.
dao.saveOne(personne);
60.
// on est pass - l'original a t modifi
61.
fini = true;
62.
63.
// on rcupre le code erreur
64.
65.
// si une erreur d'ID ou de version de code erreur 2, on ressaie la mise jour
66.
switch (codeErreur) {
67.
case 2:
68.
suivi("version corrompue ou personne inexistante");
69.
break;
70.
default:
71.
// exception non gre - on laisse remonter
72.
throw ex;
73.
}
74.
}
75.
}
76.
// suivi
77.
suivi("a termin et pass le nombre d'enfants " + (nbEnfants + 1));
78. }
79.
80. // suivi
81. private void suivi(String message) {
82.
System.out.println(name + " [" + new Date().getTime() + "] : "
83.
+ message);
84. }
85. }
Une mise jour de personne peut chouer parce que la personne quon veut modifier nexiste pas ou quelle a t mise jour
auparavant par un autre thread. Ces deux cas sont ici grs lignes 67-69. Dans ces deux cas en effet, la mthode [updatePersonne]
lance une [DaoException] de code 2. Le thread sera alors ramen recommencer la procdure de mise jour depuis son dbut
(boucle while, ligne 34).
[test6]
[test6] a pour objectif de tester la mthode [insertPersonne - DaoImplCommon]. On rappelle le code de celle-ci :
1.// ajouter une personne
2. protected void insertPersonne(Personne personne) {
3.
// 1re version
4.
personne.setVersion(1);
5.
6.
if (true)
7.
wait(10);
8.
// on insre la nouvelle personne dans la table de la BD
9.
getSqlMapClientTemplate().insert("Personne.insertOne", personne);
10. }
lignes 6-7 : on attend 10 ms pour forcer le thread qui excute [insertPersonne] perdre le processeur et augmenter ainsi
nos chances de voir apparatre des conflits dus des threads qui font des insertions en mme temps.
Le code de [test6] est le suivant :

1. // insertions multi-threads
2. public void test6() throws ParseException, InterruptedException{
3.
// cration d'une personne
4.
Personne p = new Personne(-1, "X", "X", new SimpleDateFormat(
5.
6.
// qu'on duplique N fois dans un tableau
7.
final int N = 100;
24/73
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.}
Personne[] personnes=new Personne[N];

for(int i=0;i<personnes.length;i++){
personnes[i]=new Personne(p);
}
// cration de N threads d'insertion - chaque thread insre 1 personne
Thread[] taches = new Thread[N];
taches[i] = new ThreadDaoInsertPersonne("thread n " + i, dao, personnes[i]);
taches[i].start();
}
// on attend la fin des threads
// thread n i
taches[i].join();
// supression personne
dao.deleteOne(personnes[i].getId());
}
On cre 100 threads qui vont insrer en mme temps 100 personnes diffrentes. Ces 100 threads vont tous obtenir une cl primaire
pour la personne quils doivent insrer puis tre interrompus pendant 10 ms (ligne 10 insertPersonne) avant de pouvoir faire leur
insertion. On veut vrifier que les choses se passent bien et que notamment ils obtiennent bien des valeurs de cl primaire
diffrentes.
lignes 7-11 : un tableau de 100 personnes est cr. Ces personnes sont toutes des copies de la personne p cre lignes 4-5.
lignes 14-17 : les 100 threads d'insertion sont lancs. Chacun d'eux est charg d'insrer l'une des 100 personnes cre
prcdemment..
lignes 19-23 : [test6] attend la fin de chacun des 100 threads qu'il a lancs. Lorsqu'il a dtect la fin du thread n i, il
supprime la personne que ce thread vient d'insrer.
Le thread dinsertion [ThreadDaoInsertPersonne] est le suivant :

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
lignes 19-22 : le constructeur du thread mmorise la personne qu'il doit insrer et la couche [dao] qu'il doit utiliser pour
faire cette insertion.
ligne 30 : la personne est insre. Si une exception se produit, elle remonte [test6].
import java.util.Date;
import istia.st.springmvc.personnes.dao.IDao;
public class ThreadDaoInsertPersonne extends Thread {
// nom du thread
private String name;
// rfrence sur la couche [dao]
private IDao dao;
// l'id de la personne sur qui on va travailler
private Personne personne;
// constructeur
public ThreadDaoInsertPersonne(String name, IDao dao, Personne personne) {
this.name = name;
this.dao = dao;
this.personne = personne;
}
// coeur du thread
public void run() {
// suivi
suivi("lanc");
// insertion
// suivi
suivi("a termin");
}
// suivi
private void suivi(String message) {
System.out.println(name + " [" + new Date().getTime() + "] : "
+ message);
}
Tests
25/73
Aux tests, on obtient les rsultats suivants :
- le test [test6] russit
- le test [test4] choue

Le test [test4] choue donc. Le nombre d'enfants est pass 64 au lieu de 100 attendu. Que s'est-il pass ? Examinons les logs
cran. Ils montrent l'existence d'exceptions lances par Firebird :
1.
2.
3.
4.
5.
6.
7.
8.
9.
Exception in thread "Thread-62" org.springframework.jdbc.UncategorizedSQLException: SqlMapClient

operation; uncategorized SQLException for SQL []; SQL state [HY000]; error code [335544336];
--- The error occurred in personnes-firebird.xml.
--- The error occurred while applying a parameter map.
--- Check the Personne.updateOne-InlineParameterMap.
--- Check the statement (update failed).
--- Cause: org.firebirdsql.jdbc.FBSQLException: GDS Exception. 335544336. deadlock
update conflicts with concurrent update; nested exception is
com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in personnes-firebird.xml.
--- The error occurred while applying a parameter map.
ligne 1 on a eu une exception Spring [org.springframework.jdbc.UncategorizedSQLException]. C'est une exception non

contrle qui a t utilise pour encapsuler une exception lance par le pilote JDBC de Firebird, dcrite ligne 6.
ligne 6 le pilote JDBC de Firebird a lanc une exception de type [org.firebirdsql.jdbc.FBSQLException] et de code
d'erreur 335544336.
ligne 7 : indique qu'on a eu un conflit d'accs entre deux threads qui voulaient mettre jour en mme temps la mme ligne
de la table [PERSONNES].
Ce n'est pas une erreur irrcuprable. Le thread qui intercepte cette exception peut retenter la mise jour. Il faut pour cela modifier
le code de [ThreadDaoMajEnfants] :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
try {
fini = true;
// si une erreur d'ID ou de version de code ereur 2, on ressaie la mise jour
case 2:
break;
default:
throw ex;
}
ligne 8 : on gre une exception de type [DaoException]. D'aprs ce qui a t dit, il nous faudrait grer l'exception qui est
apparue aux tests, le type [org.springframework.jdbc.UncategorizedSQLException]. On ne peut cependant pas se
contenter de grer ce type qui est un type gnrique de Spring destin encapsuler des exceptions qu'il ne connat pas.
Spring connat les exceptions mises par les pilotes JDBC d'un certain nombre de SGBD tels Oracle, MySQL, Postgres,
DB2, SQL Server, ... mais pas Firebird. Aussi toute exception lance par le pilote JDBC de Firebird se trouve-t-elle
encapsule dans le type Spring [org.springframework.jdbc.UncategorizedSQLException] :
26/73
On voit ci-dessus, que la classe [UncategorizedSQLException] drive de la classe [DataAccessException] que nous avons
voque, paragraphe 2.3.3 page 16. Il est possible de connatre l'exception qui a t encapsule dans
[UncategorizedSQLException] grce sa mthode [getSQLException] :
Cette exception de type [SQLException] est celle lance par la couche [iBATIS] qui elle mme encapsule l'exception
lance par le pilote JDBC de la base de donnes. La cause exacte de l'exception de type [SQLException] peut tre
obtenue par la mthode :
On obtient l'objet de type [Throwable] qui a t lanc par le pilote JDBC :
Le type [Throwable] est la classe parent de [Exception].

Ici il nous faudra vrifier que l'objet de type [Throwable] lanc par le pilote JDBC de Firebird et cause de l'exception
[SQLException] lance par la couche [iBATIS] est bien une exception de type [org.firebirdsql.gds.GDSException] et de code
d'erreur 335544336. Pour rcuprer le code erreur, nous pourrons utiliser la mthode [getErrorCode()] de la classe
[org.firebirdsql.gds.GDSException].
Si nous utilisons dans le code de [ThreadDaoMajEnfants] l'exception [org.firebirdsql.gds.GDSException], alors ce thread ne pourra
travailler qu'avec le SGBD Firebird. Il en sera de mme du test [test4] qui utilise ce thread. Nous voulons viter cela. En effet, nous
souhaitons que nos tests JUnit restent valables quelque soit le SGBD utilis. Pour arriver ce rsultat, on dcide que la couche
[dao] lancera une [DaoException] de code 4 lorsqu'une exception de type " conflit de mise jour " est dtecte et ce, quelque soit
le SGBD sous-jacent. Ainsi, le thread [ThreadDaoMajEnfants] pourra-t-il tre rcrit comme suit :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
...
public class ThreadDaoMajEnfants extends Thread {
...
// coeur du thread
public void run() {
...
while (!fini) {
// on rcupre une copie de la personne d'idPersonne
Personne personne = dao.getOne(idPersonne);
nbEnfants = personne.getNbEnfants();
27/73
14. ...
15.
// attente termine - on essaie de valider la copie
16.
// entre-temps d'autres threads ont pu modifier l'original
17.
int codeErreur = 0;
18.
try {
19.
20.
21.
22.
23.
24.
fini = true;
25.
26.
27.
28.
// si une erreur d'ID ou de version 2 ou un deadlock 4, on
29.
// ressaie la mise jour
30.
31.
case 2:
32.
33.
break;
34.
case 4:
35.
suivi("conflit de mise jour");
36.
break;
37.
default:
38.
39.
throw ex;
40.
}
41.
}
42.
}
43.
// suivi
44.
suivi("a termin et pass le nombre d'enfants " + (nbEnfants + 1));
45. }
46. ...
47. }
lignes 34-36 : l'exception de type [DaoException] de code 4 est intercepte. Le thread [ThreadDaoMajEnfants] va tre
forc de recommencer la procdure de mise jour son dbut (ligne 10)
Notre couche [dao] doit donc tre capable de reconnatre une exception de type " conflit de mise jour ". Celle-ci est mise par un
pilote JDBC et lui est spcifique. Cette exception doit tre gre dans la mthode [updatePersonne] de la classe [DaoImplCommon]
:
1. // modifier une personne
2.
3.
4.
if (true)
5.
wait(10);
6.
// modification
7.
8.
9.
if (n == 0)
10.
11.
12. }
Les lignes 7-11 doivent tre entoures par un try / catch. Pour le SGBD Firebird, il nous faut vrifier que l'exception qui a caus
l'chec de la mise jour est de type [org.firebirdsql.gds.GDSException] et a comme code d'erreur 335544336. Si on met ce type de
test dans [DaoImplCommon], on va lier cette classe au SGBD Firebird, ce qui n'est videmment pas souhaitable. Si on veut garder
un caractre gnraliste la classe [DaoImplCommon], il nous faut la driver et grer l'exception dans une classe spcifique
Firebird. C'est ce que nous faisons maintenant.
2.4.2
La classe [DaoImplFirebird]
Son code est le suivant :

1. package istia.st.springmvc.personnes.dao;
2.
4.
5. public class DaoImplFirebird extends DaoImplCommon {
6.
7.
8.
9.
10.
if (true)
11.
wait(10);
12.
// modification
13.
try {
14.
// on modifie la personne qui a la bonne version
28/73
15.
int n = getSqlMapClientTemplate().update("Personne.updateOne",
16.
personne);
17.
if (n == 0)
18.
19.
20.
} catch (org.springframework.jdbc.UncategorizedSQLException ex) {
21.
if (ex.getSQLException().getCause().getClass().isAssignableFrom(
22.
org.firebirdsql.jdbc.FBSQLException.class)) {
23.
org.firebirdsql.jdbc.FBSQLException cause = (org.firebirdsql.jdbc.FBSQLException) ex
24.
.getSQLException().getCause();
25.
if (cause.getErrorCode() == 335544336) {
26.
throw new DaoException(
27.
"Conflit d'accs au mme enregistrement", 4);
28.
}
29.
} else {
30.
throw ex;
31.
}
32.
}
33. }
34.
35. // attente
36. private void wait(int N) {
37.
// on attend N ms
38.
try {
39.
Thread.sleep(N);
40.
} catch (InterruptedException e) {
41.
// on affiche la trace de l'exception
42.
e.printStackTrace();
43.
return;
44.
}
45. }
46.
47. }
ligne 5 : la classe [DaoImplFirebird] drive de [DaoImplCommon], la classe que nous venons dtudier. Elle redfinit,
lignes 8-33, la mthode [updatePersonne] qui nous pose problme.
lignes 20 : nous interceptons l'exception Spring de type [UncategorizedSQLException]
lignes 21-22 : nous vrifions que l'exception sous-jacente de type [SQLException] et lance par la couche [iBATIS] a pour
cause une exception de type [org.firebirdsql.jdbc.FBSQLException]
ligne 25 : on vrifie de plus que le code erreur de cette exception Firebird est 335544336, le code d'erreur du " deadlock ".
lignes 26-27 : si toutes ces conditions sont runies, une [DaoException] de code 4 est lance.
lignes 36-44 : la mthode [wait] permet darrter le thread courant de N millisecondes. Elle na dutilit que pour les tests.
Nous sommes prts pour les tests de la nouvelle couche [dao].
2.4.3
Tests de l'implmentation [DaoImplFirebird]
Le fichier de configuration des tests [spring-config-test-dao-firebird.xml] est modifi pour utiliser l'implmentation
[DaoImplFirebird] :
3. <beans>
4.
5.
6.
7.
8.
9.
</property>
10.
11.
12.
13.
</property>
14.
15.
16.
</property>
17.
18.
19.
</property>
20. </bean>
23.
24.
25.
26.
</property>
27.
28.
29.
</property>
29/73
30. </bean>
32. <bean id="dao" class="istia.st.springmvc.personnes.dao.DaoImplFirebird">
33.
34.
35.
</property>
36. </bean>
37. </beans>
ligne 32 : la nouvelle implmentation [DaoImplFirebird] de la couche [dao].
Les rsultats du test [test4] qui avait chou prcdemment sont les suivants :
[test4] a t russi. Les dernires lignes de logs cran sont les suivantes :
1.
2.
3.
4.
5.
6.
7.
thread
thread
thread
thread
thread
thread
thread
n
n
n
n
n
n
n
36
75
36
36
36
36
36
[1145977145984]
[1145977145984]
[1145977146000]
[1145977146000]
[1145977146000]
[1145977146015]
[1145977146031]
:
:
:
:
:
:
:
fin attente
a termin et pass le nombre d'enfants 99
version corrompue ou personne inexistante
99 -> 100 pour la version 100
dbut attente
fin attente
a termin et pass le nombre d'enfants 100
La dernire ligne indique que cest le thread n 36 qui a termin le dernier. La ligne 3 montre un conflit de version qui a forc le
thread n 36 reprendre sa procdure de mise jour de la personne (ligne 4). Dautres logs montrent des conflits daccs lors des
mises jour :
1.
2.
3.
thread n 52 [1145977145765] : version corrompue ou personne inexistante

thread n 75 [1145977145765] : conflit de mise jour
thread n 36 [1145977145765] : version corrompue ou personne inexistante
La ligne 2 montre que le thread n 75 a chou lors de sa mise jour cause dun conflit de mise jour : lorsque la commande SQL
[update] a t mise sur la table [PERSONNES], la ligne quil fallait mettre jour tait verrouille par un autre thread. Ce conflit
d'accs va obliger le thread n 75 retenter sa mise jour.
Pour terminer avec [test4] on remarquera une diffrence notable avec les rsultats du mme test dans la version 1 o il avait chou
cause de problmes de synchronisation. Les mthodes de la couche [dao] de la version 1 ntant pas synchronises, des conflits
daccs apparaissaient. Ici, nous navons pas eu besoin de synchroniser la couche [dao]. Nous avons simplement gr les conflits
daccs signals par Firebird.
Excutons maintenant la totalit du test JUnit de la couche [dao] :
30/73
Il semble donc quon ait une couche [dao] valide. Pour la dclarer valide avec une forte probabilit, il nous faudrait faire davantage
de tests encore. Nanmoins, nous la considrerons comme oprationnelle.
2.5
La couche [service]
2.5.1
Les composantes de la couche [service]
La couche [service] est constitue des classes et interfaces suivantes :
[IService] est linterface prsente par la couche [service]

[ServiceImpl] est une implmentation de celle-ci
Linterface [IService] est la suivante :

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
package istia.st.springmvc.personnes.service;
linterface a les mmes quatre mthodes que dans la version 1 mais elle en a deux de plus :
saveMany : permet de sauvegarder plusieurs personnes en mme temps de faon atomique. Soit elles sont toutes
sauvegardes, soit aucune ne lest.
deleteMany : permet de supprimer plusieurs personnes en mme temps de faon atomique. Soit elles sont toutes
supprimes, soit aucune ne lest.
public interface IService {
// liste de toutes les personnes
Collection getAll();
// obtenir une personne particulire
Personne getOne(int id);
// ajouter/modifier une personne
void saveOne(Personne personne);
// supprimer une personne
void deleteOne(int id);
// sauvegarder plusieurs personnes
void saveMany(Personne[] personnes);
// supprimer plusieurs personnes

void deleteMany(int ids[]);
Ces deux mthodes ne seront pas utilises par lapplication web. Nous les avons rajoutes pour illustrer la notion de
transaction sur une base de donnes. Les deux mthodes devront en effet tre excutes au sein dune transaction pour
obtenir latomicit dsire.
La classe [ServiceImpl] implmentant cette interface sera la suivante :
1. package istia.st.springmvc.personnes.service;
2.
4. import istia.st.springmvc.personnes.dao.IDao;
5.
6. import java.util.Collection;
7.
8. public class ServiceImpl implements IService {
9.
10. // la couche [dao]
11. private IDao dao;
12.
13. public IDao getDao() {
14.
return dao;
15. }
16.
17. public void setDao(IDao dao) {
31/73
18.
this.dao = dao;
19. }
20.
23.
return dao.getAll();
24. }
25.
26. // obtenir une personne en particulier
27. public Personne getOne(int id) {
28.
return dao.getOne(id);
29. }
30.
31. // ajouter ou modifier une personne
32. public void saveOne(Personne personne) {
33.
34. }
35.
36. // suppression d'une personne
37. public void deleteOne(int id) {
38.
dao.deleteOne(id);
39. }
40.
41. // sauvegarder une collection de personnes
42. public void saveMany(Personne[] personnes) {
43.
// on boucle sur le tableau des personnes
44.
for (int i = 0; i < personnes.length; i++) {
45.
dao.saveOne(personnes[i]);
46.
}
47. }
48.
49. // supprimer une collection de personnes
50. public void deleteMany(int[] ids) {
51.
// ids : les id des personnes supprimer
52.
for (int i = 0; i < ids.length; i++) {
53.
dao.deleteOne(ids[i]);
54.
}
55. }
56. }
les mthodes [getAll, getOne, insertOne, saveOne] font appel aux mthodes de la couche [dao] de mme nom.
lignes 42-47 : la mthode [saveMany] sauvegarde, une par une, les personnes du tableau pass en paramtre.
lignes 50-55 : la mthode [deleteMany] supprime, une par une, les personnes dont on lui a pass le tableau des id en
paramtre
Nous avons dit que les mthodes [saveMany] et [deleteMany] devaient se faire au sein dune transaction pour assurer laspect tout
ou rien de ces mthodes. Nous pouvons constater que le code ci-dessus ignore totalement cette notion de transaction. Celle-ci
napparatra que dans le fichier de configuration de la couche [service].
2.5.2
Configuration de la couche [service]
Ci-dessus, ligne 11, on voit que limplmentation [ServiceImpl] dtient une rfrence sur la couche [dao]. Celle-ci, comme dans la
version 1, sera initialise par Spring au moment de linstanciation de la couche [service - ServiceImpl]. Le fichier de configuration
qui permettra linstanciation de la couche [service] sera le suivant :
3. <beans>
4.
5.
6.
7.
8.
9.
</property>
10.
11.
12.
13.
</property>
14.
15.
16.
</property>
17.
18.
19.
</property>
20. </bean>
23.
24.
25.
32/73
26.
</property>
27.
28.
29.
</property>
30. </bean>
31. 
33.
34.
35.
</property>
36. </bean>
37. 
38. <bean id="transactionManager"
39.
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
40.
41.
42.
</property>
43. </bean>
44. 
45. <bean id="service"
46.
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
47.
<property name="transactionManager">
48.
<ref local="transactionManager"/>
49.
</property>
50.
<property name="target">
51.
<bean class="istia.st.springmvc.personnes.service.ServiceImpl">
52.
<property name="dao">
53.
<ref local="dao"/>
54.
</property>
55.
</bean>
56.
</property>
57.
<property name="transactionAttributes">
58.
<props>
59.
<prop key="get*">PROPAGATION_SUPPORTS,readOnly</prop>
60.
<prop key="save*">PROPAGATION_REQUIRED</prop>
61.
<prop key="delete*">PROPAGATION_REQUIRED</prop>
62.
</props>
63.
</property>
64. </bean>
65. </beans>
lignes 1-36 : configuration de la couche [dao]. Cette configuration a t explique lors de ltude de la couche [dao] au
paragraphe 2.3.2 page 12.
lignes 38-64 : configurent la couche [service]
Ligne 46, on peut voir que limplmentation de la couche [service] est faite par le type [TransactionProxyFactoryBean]. On
sattendait trouver le type [ServiceImpl]. [TransactionProxyFactoryBean] est un type prdfini de Spring. Comment se peut-il
quun type prdfini puisse implmenter linterface [IService] qui elle, est spcifique notre application ?
Dcouvrons tout dabord la classe [TransactionProxyFactoryBean] :
Nous voyons quelle implmente linterface [FactoryBean]. Nous avons dj rencontr cette interface. Nous savons que lorsquune
application demande Spring, une instance dun type implmentant [FactoryBean], Spring rend non pas une instance [I] de ce type,
mais lobjet rendu par la mthode [I].getObject() :
Dans notre cas, la couche [service] va tre implmente par lobjet rendu par [TransactionProxyFactoryBean].getObject(). Quelle est la
nature de cet objet ? Nous nallons pas rentrer dans les dtails car ils sont complexes. Ils relvent de ce quon appelle Spring AOP
(Aspect Oriented Programming). Nous allons tenter dclaircir les choses avec de simples schmas. AOP permet la chose suivante :
on a deux classes C1 et C2, C1 utilisant l'interface [I2] prsente par C2 :
33/73
[C1]
[C2]
grce AOP, on peut placer, de faon transparente pour les deux classes, un intercepteur entre les classes C1 et C2 :
[C1]
[intercepteur]
2 [C2]
La classe [C1] a t compile pour travailler avec l'interface [I2] que [C2] implmente. Au moment de lexcution, AOP
vient placer la classe [intercepteur] entre [C1] et [C2]. Pour que cela soit possible, il faut bien sr que la classe
[intercepteur] prsente [C1] la mme interface [I2] que [C2].
A quoi cela peut-il servir ? La documentation Spring donne quelques exemples. On peut vouloir faire, par exemple, des
logs l'occasion des appels une mthode M particulire de [C2], pour faire un audit de cette mthode. Dans
[intercepteur], on crira alors une mthode [M] qui fait ces logs. Lappel de [C1] [C2].M va se passer ainsi (cf schma cidessus) :
1.
2.
3.
4.
[C1] appelle la mthode M de [C2]. Cest en fait la mthode M de [intercepteur] qui sera appele. Cela est
possible si [C1] sadresse une interface [I2] plutt qu une implmentation particulire de [I2]. Il suffit alors
que [intercepteur] implmente [I2].
la mthode M de [intercepteur] fait les logs et appelle la mthode M de [C2] vise initialement par [C1].
la mthode M de [C2] sexcute et rend son rsultat la mthode M de [intercepteur] qui peut ventuellement
ajouter quelque chose ce qui a t fait en 2.
la mthode M de [intercepteur] rend un rsultat la mthode appelante de [C1]
On voit que la mthode M de [intercepteur] peut faire quelque chose avant et aprs lappel de la mthode M de [C2]. Vis
vis de [C1], elle enrichit donc la mthode M de [C2]. On peut donc voir la technologie AOP comme une faon denrichir
linterface prsente par une classe.
Comment ce concept sapplique-t-il notre couche [service] ? Si on implmente la couche [service] directement avec une instance
[ServiceImpl], notre application web aura larchitecture suivante :
[web]
[service]
[ServiceImpl]
[dao]
[DaoImplCommon]
Si on implmente la couche [service] avec une instance [TransactionProxyFactoryBean], on aura larchitecture suivante :
[web]
[proxy 2
transactionnel]
[service] 3
[ServiceImpl]
[dao]
[DaoImplCommon]
On peut dire que la couche [service] est instancie avec deux objets :
lobjet que nous appelons ci-dessus [proxy transactionnel] et qui est en fait lobjet rendu par la mthode [getObject] de
[TransactionProxyFactoryBean]. Cest cet objet qui fera linterface de la couche [service] avec la couche [web]. Il
implmente par construction linterface [IService].
une instance [ServiceImpl] qui elle aussi implmente linterface [IService]. Elle seule sait comment travailler avec la couche
[dao], aussi est-elle ncessaire.
Imaginons que la couche [web] appelle la mthode [saveMany] de linterface [IService]. Nous savons que fonctionnellement, les
ajouts / mises jour faits par cette mthode doivent l'tre dans une transaction. Soit ils russissent tous, soit aucun nest fait. Nous
34/73
avons prsent la mthode [saveMany] de la classe [ServiceImpl] et nous avons point le fait quelle navait pas la notion de
transaction. La mthode [saveMany] du [proxy transactionnel] va enrichir la mthode [saveMany] de la classe [ServiceImpl] avec
cette notion de transaction. Suivons le schma ci-dessus :
1.
2.
3.
4.
5.
6.
la couche [web] appelle la mthode [saveMany] de linterface [IService].

la mthode [saveMany] de [proxy transactionnel] est excute. Elle commence une transaction. Il faut quelle ait
les informations suffisantes pour le faire, notamment un objet [DataSource] pour obtenir une connexion au
SGBD. Puis elle fait appel la mthode [saveMany] de [ServiceImpl].
celle-ci sexcute. Elle fait appel de faon rpte la couche [dao] pour excuter les insertions ou les mises
jour. Les ordres SQL excuts cette occasion le sont dans la transaction commence en 2.
supposons quune de ces oprations choue. La couche [dao] va laisser remonter une exception vers la couche
[service], en loccurrence la mthode [saveMany] de linstance [ServiceImpl].
celle-ci ne fait rien et laisse remonter lexception jusqu la mthode [saveMany] de [proxy transactionnel].
rception de lexception, la mthode [saveMany] de [proxy transactionnel] qui est propritaire de la transaction
fait un [rollback] de celle-ci pour annuler la totalit des mises jour, puis laisse remonter lexception jusqu la
couche [web] qui sera charge de la grer.
A ltape 4, nous avons suppos quune des insertions ou des mises jour chouait. Si ce nest pas le cas, en [5] aucune
exception ne remonte. Idem en [6]. Dans ce cas, la mthode [saveMany] de [proxy transactionnel] fait un [commit] de la
transaction pour valider la totalit des mises jour.
Nous avons maintenant une ide plus prcise de larchitecture mise en place par le bean [TransactionProxyFactoryBean]. Revenons
sur la configuration de celui-ci :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.


<bean id="transactionManager"
</property>
</bean>

<bean id="service"
</property>
<ref local="dao"/>
</property>
</bean>
</property>
<props>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
Suivons cette configuration la lumire de larchitecture qui est configure :
[web]
[proxy 2
transactionnel]
[service] 3
[ServiceImpl]
[dao]
[DaoImplCommon]
[proxy transactionnel] va grer les transactions. Spring offre plusieurs stratgies de gestion de celles-ci. [proxy
transactionnel] a besoin dune rfrence sur le gestionnaire de transactions choisi.
lignes 11 13 : dfinissent lattribut [transactionManager] du bean [TransactionProxyFactoryBean] avec une rfrence sur
un gestionnaire de transactions. Celui-ci est dfini lignes 2 7.
lignes 2-7 : le gestionnaire de transactions est de type [DataSourceTransactionManager] :
35/73
[DataSourceTransactionManager] est un gestionnaire de transactions adapt aux SGBD accds via un objet
[DataSource]. Il ne sait grer que les transactions sur un unique SGBD. Il ne sait pas grer des transactions distribues sur
plusieurs SGBD. Ici, nous navons quun seul SGBD. Aussi ce gestionnaire de transactions convient-il. Lorsque [proxy
transactionnel] va dmarrer une transaction, il va le faire sur une connexion attache au thread. Cest cette connexion qui
sera utilise dans toutes les couches qui mnent la base de donnes : [ServiceImpl, DaoImplCommon,
SqlMapClientTemplate, JDBC].
La classe [DataSourceTransactionManager] a besoin de connatre la source de donnes auprs de laquelle elle doit
demander une connexion pour lattacher au thread. Celle-ci est dfinie lignes 4-6 : cest la mme source de donnes que
celle utilise par la couche [dao] (cf paragraphe 2.5.2, page 32).
lignes 14-19 : lattribut " target " indique la classe qui doit tre intercepte, ici la classe [ServiceImpl]. Cette information est
ncessaire pour deux raisons :
la classe [ServiceImpl] doit tre instancie puisque cest elle qui assure le dialogue avec la couche [dao]
[TransactionProxyFactoryBean] doit gnrer un proxy qui prsente la couche [web] la mme interface que
[ServiceImpl].
lignes 21-27 : indiquent quelles mthodes de [ServiceImpl], le proxy doit intercepter. Lattribut [transactionAttributes],
ligne 21, indique quelles mthodes de [ServiceImpl] ncessitent une transaction et quels sont les attributs de celle-ci :
ligne 23 : les mthodes dont le nom commencent par get [getOne, getAll] sexcutent dans une transaction
dattribut [PROPAGATION_REQUIRED,readOnly] :
PROPAGATION_REQUIRED : la mthode sexcute dans une transaction s'il y en a dj une attache au

thread, sinon une nouvelle est cre et la mthode sexcute dedans.
readOnly : transaction en lecture seule
Ici les mthodes [getOne] et [getAll] de [ServiceImpl] sexcuteront dans une transaction alors qu'en fait ce n'est
pas ncessaire. Il s'agit chaque fois d'une opration constitue d'un unique ordre SELECT. On ne voit pas l'utilit
de mettre ce SELECT dans une transaction.
ligne 24 : les mthodes dont le nom commencent par save, [saveOne, saveMany] sexcutent dans une transaction
dattribut [PROPAGATION_REQUIRED].
ligne 25 : les mthodes [deleteOne] et [deleteMany] de [ServiceImpl] sont configures de faon identique aux
mthodes [saveOne, saveMany].
Dans notre couche [service], seules les mthodes [saveMany] et [deleteMany] ont besoin de sexcuter dans une transaction. La
configuration aurait pu tre rduite aux lignes suivantes :
1.
2.
<props>
3.
<prop key="saveMany">PROPAGATION_REQUIRED</prop>
4.
<prop key="deleteMany">PROPAGATION_REQUIRED</prop>
5.
</props>
6. </property>
2.6
Tests de la couche [service]
Maintenant que nous avons crit et configur la couche [service], nous nous proposons de la tester avec des tests JUnit :
36/73
Le fichier de configuration [spring-config-test-service-firebird.xml] de la couche [service] est celui qui a t dcrit au paragraphe
2.5.2, page 32.
Le test JUnit [TestServiceFirebird] est le suivant :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
...
public class TestServiceFirebird extends TestCase {
// couche [service]
private IService service;
public IService getService() {
return service;
}
public void setService(IService service) {
this.service = service;
}
// setup
public void setUp() {
service = (IService) (new XmlBeanFactory(new ClassPathResource(
"spring-config-test-service-firebird.xml"))).getBean("service");
}
private void doListe(Collection personnes) {
...
}
// test1
...
}
// modification-suppression d'un lment inexistant
...
}
// gestion des versions de personne
public void test3() throws ParseException, InterruptedException {
...
}
// optimistic locking - accs multi-threads
...
}
// tests de validit de saveOne
...
}
// insertions multi-threads
public void test6() throws ParseException, InterruptedException{
...
}
// tests de la mthode deleteMany
// liste actuelle
Collection personnes = service.getAll();
int nbPersonnes1 = personnes.size();
// affichage
doListe(personnes);
// cration de trois personnes
Personne p1 = new Personne(-1, "X", "X", new SimpleDateFormat(
Personne p2 = new Personne(-1, "Y", "Y", new SimpleDateFormat(
"dd/MM/yyyy").parse("01/03/2006"), false, 0);
Personne p3 = new Personne(-2, "Z", "Z", new SimpleDateFormat(
// ajout des 3 personnes - la personne p3 avec l'id -2 va provoquer
// une exception
boolean erreur = false;
try {
service.saveMany(new Personne[] { p1, p2, p3 });
erreur = true;
37/73
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155. }
156.
157.}
System.out.println(ex.toString());
}
// vrification
assertTrue(erreur);
// nouvelle liste - le nombre d'lments n'a pas du changer
// cause rollback automatique de la transaction
int nbPersonnes2 = service.getAll().size();
assertEquals(nbPersonnes1, nbPersonnes2);
// ajout des deux personnes valides
// on remet leur id -1
p1.setId(-1);
p2.setId(-1);
service.saveMany(new Personne[] { p1, p2 });
// on rcupre leurs id
// vrifications
p1 = service.getOne(id1);
assertEquals(p1.getNom(), "X");
assertEquals(p2.getNom(), "Y");
// nouvelle liste - on doit avoir 2 lments de +
int nbPersonnes3 = service.getAll().size();
assertEquals(nbPersonnes1 + 2, nbPersonnes3);
// suppression de p1 et p2 et d'une personne inexistante
// une exception doit se produire
erreur = false;
try {
service.deleteMany(new int[] { id1, id2, -1 });
erreur = true;
System.out.println(ex.toString());
}
// vrification
assertTrue(erreur);
// nouvelle liste
personnes = service.getAll();
// aucune personne n'a du tre supprime (rollback
// automatique de la transaction)
// on supprime les deux personnes valides
service.deleteMany(new int[] { id1, id2 });
// vrifications
// personne p1
erreur = false;
int codeErreur = 0;
try {
erreur = true;
}
assertTrue(erreur);
// personne p2
erreur = false;
codeErreur = 0;
try {
erreur = true;
}
assertTrue(erreur);
// nouvelle liste
personnes = service.getAll();
// vrification - on doit tre revenu au point de dpart
// affichage
doListe(personnes);
lignes 19-22 : le programme teste des couches [dao] et [service] configures par le fichier [spring-config-test-servicefirebird.xml], celui tudi dans la section prcdente.
les tests [test1] [test6] sont identiques dans leur esprit leurs homologues de mme nom dans la classe de test
[TestDaoFirebird] de la couche [dao]. La seule diffrence est que par configuration, les mthodes [saveOne] et
[deleteOne] sexcutent dsormais dans une transaction.
38/73
la mthode [test7] a pour but de tester les mthodes [saveMany] et [deleteMany]. On veut vrifier quelles sexcutent bien
dans une transaction. Commentons le code de cette mthode :
lignes 62-63 : on compte le nombre de personnes [nbPersonnes1] actuellement dans la liste

lignes 67-72 : on cre trois personnes
lignes 73-83 : ces trois personnes sont sauvegardes par la mthode [saveMany] ligne 77. Les deux premires personnes
p1 et p2 ayant un id gal -1 vont tre ajoutes la table [PERSONNES]. La personne p3 a elle un id gal -2. Il ne sagit
donc pas dune insertion mais dune mise jour. Celle-ci va chouer car il ny a aucune personne avec un id gal 2 dans
la table [PERSONNES]. La couche [dao] va donc lancer une exception qui va remonter jusqu la couche [service].
Lexistence de cette exception est teste ligne 83.
cause de lexception prcdente, la couche [service] devrait faire un [rollback] de lensemble des ordres SQL mis
pendant lexcution de la mthode [saveMany], ceci parce que cette mthode sexcute dans une transaction. Lignes 86-87,
on vrifie que le nombre de personnes de la liste na pas boug et que donc les insertions de p1 et p2 nont pas eu lieu.
lignes 88-103 : on ajoute les seules personnes p1 et p2 et on vrifie quensuite on a deux personnes de plus dans la liste.
lignes 106-114 : on supprime un groupe de personnes constitu des personnes p1 et p2 quon vient dajouter et dune
personne inexistante (id= -1). La mthode [deleteMany] est utilise pour cela, ligne 108. Cette mthode va chouer car il
ny a aucune personne avec un id gal 1 dans la table [PERSONNES]. La couche [dao] va donc lancer une exception
qui va remonter jusqu la couche [service]. Lexistence de cette exception est teste ligne 114.
cause de lexception prcdente, la couche [service] devrait faire un [rollback] de lensemble des ordres SQL mis
pendant lexcution de la mthode [deleteMany], ceci parce que cette mthode sexcute dans une transaction. Lignes 116117, on vrifie que le nombre de personnes de la liste na pas boug et que donc les suppressions de p1 et p2 nont pas eu
lieu.
ligne 122 : on supprime un groupe constitu des seules personnes p1 et p2. Cela devrait russir. Le reste de la mthode
vrifie que cest bien le cas.
Lexcution des tests donne les rsultats suivants :
Les sept tests ont t russis. Nous considrerons notre couche [service] comme oprationnelle.
2.7
La couche [web]
Rappelons larchitecture gnrale de lapplication web construire :

utilisateur
DispatcherServlet
1
Couche service
[service]
2
3
Controller
4
View
Couche d'accs
aux donnes
[dao]
Donnes
Modle Map
6
Nous venons de construire les couches [dao] et [service] permettant de travailler avec une base de donnes Firebird. Nous avons
crit une version 1 de cette application o les couches [dao] et [service] travaillaient avec une liste de personnes en mmoire. La
couche [web] crite cette occasion reste valide. En effet, elle sadressait une couche [service] implmentant linterface [IService].
La nouvelle couche [service] implmentant cette mme interface, la couche [web] na pas tre modifie.
39/73
Dans le prcdent article, la version 1 de lapplication avait t teste avec le projet Eclipse [spring-mvc-37B] o les couches [web,
service, dao] avaient t mises dans des archives .jar :
Le dossier [WEB-INF/src] tait vide. Les classes des trois couches taient dans les trois archives [personnes-*.jar ] :
archive de la couche [service]

archive de la couche [dao]
archive de la couche [web]
Pour tester la version 2, nous dupliquons le dossier [mvc-37B] du projet [spring-mvc-37B] en [mvc-38B] :
Nous modifions le fichier [.project] afin quil rfrence un projet Eclipse appel [spring-mvc-38B] :
1.
2.
3.
4.
<projectDescription>
<name>spring-mvc-38B</name>
<comment></comment>
...
Nous faisons de mme avec le fichier [.tomcatplugin] pour rfrencer une application web de contexte [/spring-mvc-38B] :
1.
2.
3.
<extraInfo></extraInfo>
<webPath>/spring-mvc-38B</webPath>
</tomcatProjectProperties>
40/73
Ensuite nous importons ce projet sous Eclipse [File / Import / Existing projects] :
Dans le projet [spring-mvc-38], nous exportons [File / Export / Jar file] les couches [dao] et [service] respectivement dans les
archives [personnes-dao.jar] et [personnes-service.jar] du dossier [dist] du projet :
Nous copions ces deux fichiers, puis sous Eclipse nous les collons dans le dossier [WEB-INF/lib] o ils vont remplacer les
archives de mme nom de la version prcdente.
En procdant de la mme faon, nous copions les archives [commons-dbcp-*.jar, commons-pool-*.jar, firebirdsql-full.jar, ibatiscommon-2.jar, ibatis-sqlmap-2.jar] du dossier [lib] du projet [spring-mvc-38] dans le dossier [WEB-INF/lib] du projet [spring-mvc38B]. Ces archives sont ncessaires aux nouvelles couches [dao] et [service].
Ceci fait, nous incluons les nouvelles archives dans le Classpath du projet : [clic droit sur projet -> Properties -> Java Build Path ->
Add Jars].
41/73
Le fichier [applicationContext.xml] configure les couches [dao] et [service] de lapplication web. Dans la nouvelle version, il est
identique au fichier [spring-config-test-service-firebird.xml] qui a servi pour configurer le test de la couche service dans le projet
[spring-mvc-38]. On fait donc un copier / coller de lun vers lautre :
3. <beans>
4.
5.
6.
7.
8.
9.
</property>
10.
11.
12.
13.
</property>
14.
15.
16.
</property>
17.
18.
19.
</property>
20. </bean>
23.
24.
25.
26.
</property>
27.
28.
29.
</property>
30. </bean>
31. 
33.
34.
35.
</property>
36. </bean>
37. 
38. <bean id="transactionManager"
39.
40.
41.
42.
</property>
43. </bean>
44. 
45. <bean id="service"
46.
47.
48.
49.
</property>
50.
51.
52.
53.
<ref local="dao"/>
54.
</property>
42/73
55.
</bean>
56.
</property>
57.
58.
<props>
59.
<prop key="get*">PROPAGATION_SUPPORTS,readOnly</prop>
60.
61.
62.
</props>
63.
</property>
64. </bean>
65. </beans>
ligne 12 : lurl de la base de donnes Firebird. Nous continuons utiliser la base qui a servi aux tests des couches [dao] et
[service]
Nous dclarons le contexte de la nouvelle application web [clic droit sur projet -> Projet Tomcat -> Mise jour du contexte] :
Nous sommes prts pour les tests. Le SGBD Firebird est lanc. Le contenu de la table [PERSONNES] est alors le suivant :
Tomcat est lanc son tour. Avec un navigateur, nous demandons lurl [http://localhost:8080/spring-mvc-38B] :
Nous ajoutons une nouvelle personne avec le lien [Ajout] :
43/73
Nous vrifions lajout dans la base de donnes :
Le lecteur est invit faire dautres tests [modification, suppression].

Faisons maintenant le test de conflits de version qui avait t fait dans la version 1. [Firefox] sera le navigateur de lutilisateur U1.
Celui-ci demande lurl [http://localhost:8080/spring-mvc-38B/list.html] :
[IE] sera le navigateur de lutilisateur U2. Celui-ci demande la mme Url :
44/73
Lutilisateur U1 entre en modification de la personne [Perrichon] :
Lutilisateur U2 fait de mme :
Lutilisateur U1 fait des modifications et valide :
rponse du serveur
validation
Lutilisateur U2 fait de mme :
45/73
validation
le conflit de version a t dtect

Lutilisateur U2 revient la liste des personnes avec le lien [Annuler] du formulaire :
Il trouve la personne [Perrichon] telle que U1 la modifie (nom pass en majuscules).

Et la base de donnes dans tout a ? Regardons :
La personne n 654 a bien son nom en majuscules suite la modification faite par U1.
2.8
Conclusion
Rappelons ce que nous voulions faire. Nous avions une application web avec larchitecture 3tier suivante :
46/73

utilisateur
DispatcherServlet
1
Couche service
[service]
2
3
Controller
4
Couche d'accs
aux donnes
[dao]
Donnes
Modle Map
View
o les couches [dao] et [service] travaillaient avec une liste de donnes en mmoire qui tait donc perdue lorsque le serveur web
tait arrt. Ctait la version 1. Dans la version 2, les couches [service] et [dao] ont t rcrites pour que la liste de personnes soit
dans une table de base de donnes. Elle est donc dsormais persistante. On se propose maintenant de voir limpact qua sur notre
application le changement de SGBD. Pour cela, nous allons construire trois nouvelles versions de notre application web :
version 3 : le SGBD est Postgres

version 4 : le SGBD est MySQL
version 5 : le SGBD est SQL Server Express 2005
Les changements se font aux endroits suivants :
la classe [DaoImplFirebird] implmente des fonctionnalits de la couche [dao] lies au SGBD Firebird. Si ce besoin
persiste, elle sera remplace respectivement par les classes [DaoImplPostgres], [DaoImplMySQL] et [DaoImplSqlExpress].
le fichier de mapping [personnes-firebird.xml] diBATIS pour le SGBD Firebird va tre remplac respectivement par les
fichiers de mapping [personnes-postgres.xml], [personnes-mysql.xml] et [personnes-sqlexpress.xml].
la configuration de lobjet [DataSource] de la couche [dao] est spcifique un SGBD. Elle va donc changer chaque
version.
le pilote JDBC du SGBD change galement chaque version
En-dehors de ces points, tout reste lidentique. Dans la suite, nous dcrivons ces nouvelles versions en ne nous attachant quaux
seules nouveauts amenes par chacune d'elles.
3 Spring MVC dans une architecture 3tier Exemple 4 - Postgres

3.1
La base de donnes Postgres
Dans cette version, nous allons installer la liste des personnes dans une table de base de donnes Postgres 8.x
[http://www.postgres.org]. Dans ce qui suit, les copies dcran proviennent du client EMS PostgreSQL Manager Lite
[http://www.sqlmanager.net/fr/products/postgresql/manager], un client dadministration gratuit du SGBD Postgres.
La base de donnes sappelle [dbpersonnes]. Elle contient une table [PERSONNES] :
47/73
suivants :
1. CREATE TABLE "public"."PERSONNES" (
2.
"ID" INTEGER NOT NULL,
3.
"VERSION" INTEGER NOT NULL,
4.
"NOM" VARCHAR(30) NOT NULL,
5.
"PRENOM" VARCHAR(30) NOT NULL,
6.
"DATENAISSANCE" DATE NOT NULL,
7.
"MARIE" BOOLEAN NOT NULL,
8.
"NBENFANTS" INTEGER NOT NULL,
9.
CONSTRAINT "PERSONNES_pkey" PRIMARY KEY("ID"),
10.
CONSTRAINT "PERSONNES_chk_NBENFANTS" CHECK ("NBENFANTS" >= 0),
11.
CONSTRAINT "PERSONNES_chk_NOM" CHECK (("NOM")::text <> ''::text),
12.
CONSTRAINT "PERSONNES_chk_PRENOM" CHECK (("PRENOM")::text <> ''::text)
13. ) WITH OIDS;
Nous ninsistons pas sur cette table qui est analogue la table [PERSONNES] de type Firebird tudie prcdemment. On notera
cependant que les noms des colonnes et des tables sont entre guillemets. Par ailleurs, ces noms sont sensibles la casse. Il est
possible que ce mode de fonctionnement de Postgres 8.x soit configurable. Je nai pas creus la question.
Outre la table [PERSONNES], la base [dbpersonnes] a, un objet appel squence et nomm [SEQ_ID]. Ce gnrateur dlivre des
nombres entiers successifs que nous utiliserons pour donner sa valeur la cl primaire [ID] de la classe [PERSONNES]. Prenons
un exemple pour illustrer son fonctionnement :
48/73
- la prochaine valeur du gnrateur est 38
- double-cliquer sur [SEQ_ID]
- mettons lordre SQL ci-dessus (F12) ->
- la valeur obtenue est la valeur [Next value] de la squence

[SEQ_ID]
On peut constater que la valeur [Next value] de la squence [SEQ_ID] a chang (double-clic dessus + F5 pour rafrachir) :
Lordre SQL
SELECT nextval('"SEQ_ID"')
permet donc davoir la valeur suivante de la squence [SEQ_ID]. Nous lutiliserons dans le fichier [personnes-postgres.xml] qui
rassemble les ordres SQL mis sur le SGBD.
3.2
Pour dvelopper les couches [dao] et [service] de notre application avec la base de donnes Postgres 8.x, nous utiliserons le projet
Eclipse [spring-mvc-39] suivant :
49/73
Le projet est un simple projet Java, pas un projet web Tomcat.

Dossier [src]
Tous les fichiers ayant [postgres] dans leur nom ont pu subir ou non une modfication vis vis de la version Firebird.Dans ce qui
suit, nous dcrivons les fichiers modifis.
Dossier [database]
Ce dossier contient le script de cration de la base de donnes Postgres des personnes :
1. -- EMS PostgreSQL Manager Lite 3.1.0.1

2. -- --------------------------------------3. -- Host
: localhost
4. -- Database : dbpersonnes
5.
6.
7.
8. -9. -- Definition for function plpgsql_call_handler (OID = 17230) :
10. -11. ...
12. -13. -- Structure for table PERSONNES (OID = 17254) :
14. -15. CREATE TABLE "PERSONNES" (
16.
"ID" integer NOT NULL,
17.
"VERSION" integer NOT NULL,
18.
"NOM" varchar(30) NOT NULL,
19.
"PRENOM" varchar(30) NOT NULL,
20.
"DATENAISSANCE" date NOT NULL,
21.
"MARIE" boolean NOT NULL,
50/73
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
"NBENFANTS" integer NOT NULL,

CONSTRAINT "PERSONNES_chk_NBENFANTS" CHECK (("NBENFANTS" >= 0)),
CONSTRAINT "PERSONNES_chk_NOM" CHECK ((("NOM")::text <> ''::text)),
CONSTRAINT "PERSONNES_chk_PRENOM" CHECK ((("PRENOM")::text <> ''::text))
);
--- Definition for sequence SEQ_ID (OID = 17261) :
-CREATE SEQUENCE "SEQ_ID"
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;
--- Data for blobs (OID = 17254) (LIMIT 0,3)
-INSERT INTO "PERSONNES" ("ID", "VERSION", "NOM", "PRENOM", "DATENAISSANCE", "MARIE", "NBENFANTS")
VALUES (1, 1, 'Major', 'Joachim', '1984-11-13', true, 2);
INSERT INTO "PERSONNES" ("ID", "VERSION", "NOM", "PRENOM", "DATENAISSANCE", "MARIE", "NBENFANTS")
VALUES (2, 1, 'Humbort', 'Mlanie', '1985-01-12', false, 1);
INSERT INTO "PERSONNES" ("ID", "VERSION", "NOM", "PRENOM", "DATENAISSANCE", "MARIE", "NBENFANTS")
VALUES (3, 1, 'Lemarchand', 'Charles', '1986-01-01', false, 0);
--- Definition for index PERSONNES_pkey (OID = 17256) :
-ALTER TABLE ONLY "PERSONNES"
ADD CONSTRAINT "PERSONNES_pkey" PRIMARY KEY ("ID");
--- Data for sequence public."SEQ_ID" (OID = 17261)
-SELECT pg_catalog.setval('"SEQ_ID"', 37, true);
--- Comments
-COMMENT ON SCHEMA public IS 'Standard public schema';
Dossier [lib]
On notera la prsence du pilote jdbc du SGBD Postgres 8.x. Toutes ces archives font partie du Classpath du projet Eclipse.
Dossier [dist]
Ce dossier contient les archives issues de la compilation des classes de lapplication :
3.3

La couche [dao]
La couche [dao] est la suivante :
51/73
Nous ne prsentons que ce qui change vis vis de la version [Firebird].

Le fichier de mapping [personne-postgres.xml] est le suivant :
1. <?xml version="1.0" encoding="UTF-8" ?>
2.
3. <!DOCTYPE sqlMap
4.
5.
6.
7. 
9.
10. <sqlMap>
11.
12.
13.
14.
15.
16.
class="istia.st.springmvc.personnes.entites.Personne">
17.
18.
19.
20.
21.
22.
23.
24.
</resultMap>
25.
26.
<select id="Personne.getAll" resultMap="Personne.map" > select "ID",
27.
"VERSION", "NOM", "PRENOM", "DATENAISSANCE", "MARIE", "NBENFANTS" FROM
28.
"PERSONNES"</select>
29.

30.
<select id="Personne.getOne" resultMap="Personne.map" >select "ID",
31.
"VERSION", "NOM", "PRENOM", "DATENAISSANCE", "MARIE", "NBENFANTS" FROM
32.
"PERSONNES" WHERE "ID"=#value#</select>
33.

34.
35.
36.
SELECT nextval('"SEQ_ID"') as value
37.
</selectKey>
38.
insert into "PERSONNES"("ID", "VERSION",
39.
"NOM", "PRENOM", "DATENAISSANCE", "MARIE", "NBENFANTS") VALUES(#id#,
40.
#version#, #nom#, #prenom#, #dateNaissance#, #marie#, #nbEnfants#)
41.
</insert>
42.
43.
44.
"PERSONNES" set "VERSION"=#version#+1, "NOM"=#nom#, "PRENOM"=#prenom#,
45.
"DATENAISSANCE"=#dateNaissance#, "MARIE"=#marie#, "NBENFANTS"=#nbEnfants#
46.
WHERE "ID"=#id# and "VERSION"=#version#</update>
47.

48.
<delete id="Personne.deleteOne" parameterClass="int"> delete FROM
49.
"PERSONNES" WHERE "ID"=#value# </delete>
50. </sqlMap>
Cest le mme contenu que [personnes-firebird.xml] aux dtails prs suivants :
les noms des colonnes et des tables sont entre guillemets et ces noms sont sensibles la casse
lordre SQL " Personne.insertOne " a chang lignes 34-41. La faon de gnrer la cl primaire avec Postgres est diffrente
de celle utilise avec Firebird :
52/73
ligne 36 : lordre SQL [SELECT nextval('"SEQ_ID"')] fournit la cl primaire. La syntaxe [as value] est obligatoire.
[value] reprsente la cl obtenue. Cette valeur va tre affecte au champ de lobjet [Personne] dsign par lattribut
[keyProperty] (line 35), ici le champ [id].
les ordres SQL de la balise <insert> sont excuts dans lordre o ils sont rencontrs. Donc le SELECT est fait
avant lINSERT. Au moment de lopration dinsertion, le champ [id] de lobjet [Personne] aura donc t mis jour
par lordre SQL SELECT.
lignes 38-40 : insertion de lobjet [Personne]
La classe dimplmentation [DaoImplCommon] de la couche [dao] est celle tudie dans la version [Firebird].
La configuration de la couche [dao] a t adapte au SGBD [Postgres]. Ainsi, le fichier de configuration [spring-config-test-daopostgres.xml] est-il le suivant :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
<?xml version="1.0" encoding="ISO_8859-1"?>

<!DOCTYPE beans SYSTEM "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<value>org.postgresql.Driver</value>
</property>
<value>jdbc:postgresql:dbpersonnes</value>
</property>
<value>postgres</value>
</property>
<value>postgres</value>
</property>
</bean>

<bean id="sqlMapClient"
</property>
<value>classpath:sql-map-config-postgres.xml</value>
</property>
</bean>

<bean id="dao" class="istia.st.springmvc.personnes.dao.DaoImplCommon">
</property>
</bean>
</beans>
lignes 5-19 : le bean [dataSource] dsigne maintenant la base [Postgres] [dbpersonnes] dont ladministrateur est [postgres]
avec le mot de passe [postgres]. Le lecteur modifiera cette configuration selon son propre environnement.
ligne 31 : la classe [DaoImplCommon] est la classe d'implmentation de la couche [dao]
Ces modifications faites, on peut passer aux tests.
3.4
Les tests des couches [dao] et [service]
Les tests des couches [dao] et [service] sont les mmes que pour la version [Firebird]. Les rsultats obtenus sont les suivants :
53/73
- couche [dao]
- couche [service]
On constate que les tests ont t passs avec succs avec l'implmentation [DaoImplCommon]. Nous n'aurons pas driver cette
classe comme il avait t ncessaire de le faire avec le SGBD [Firebird].
3.5
Tests de lapplication [web]
Pour tester lapplication web avec le SGBD [Postgres], nous construisons un projet Eclipse [spring-mvc-39B] de faon analogue
celle utilise pour construire le projet [spring-mvc-38B] avec la base Firebird (cf page 39).
Le SGBD Postgres est lanc. Le contenu de la table [PERSONNES] est alors le suivant :
54/73
4 Spring MVC dans une architecture 3tier Exemple 4 - MySQL

4.1
La base de donnes MySQL
Dans cette version, nous allons installer la liste des personnes dans une table de base de donnes MySQL 4.x. Nous avons utilis le
paquetage [Apache MySQL PHP] disponible l'url [http://www.easyphp.org]. Dans ce qui suit, les copies dcran proviennent
du client EMS MySQL Manager Lite [http://www.sqlmanager.net/fr/products/mysql/manager], un client dadministration gratuit
du SGBD MySQL.
suivants :
1. CREATE TABLE `personnes` (
2.
ÌD` int(11) NOT NULL auto_increment,
3.
`VERSION` int(11) NOT NULL default '0',
4.
`NOM` varchar(30) NOT NULL default '',
5.
`PRENOM` varchar(30) NOT NULL default '',
6.
`DATENAISSANCE` date NOT NULL default '0000-00-00',
7.
`MARIE` tinyint(4) NOT NULL default '0',
8.
`NBENFANTS` int(11) NOT NULL default '0',
9.
PRIMARY KEY (ÌD`)
10. ) ENGINE=InnoDB DEFAULT CHARSET=latin1
55/73
MySQL 4.x semble plus pauvre que les deux SGBD prcdents. Je n'ai pas pu mettre de contraintes (checks) la table.
ligne 10 : la table doit avoir le type [InnoDB] et non le type [MyISAM] qui ne supporte pas les transactions.
ligne 2 : la cl primaire est de type auto_increment. Si on insre une ligne sans valeur pour la colonne ID de la table,
MySQL gnrera automatiquement un nombre entier pour cette colonne. Cela va nous viter de gnrer les cls primaires
nous-mmes.
Nous savons que lors de l'insertion d'un objet [Personne] par notre couche [dao], le champ [id] de cet objet est gal -1 avant
l'insertion et a une valeur diffrente de -1 ensuite, cette valeur tant la cl primaire affecte la nouvelle ligne insre dans la table
[PERSONNES]. Voyons sur un exemple comment nous allons pouvoir connatre cette valeur.
- on excute l'ordre SELECT ci-dessus

- on excute l'ordre d'insertion ci-dessus (F12). On notera qu'on ne donne pas de valeur pour connatre la dernire valeur
au champ ID ->
insre dans le champ ID de la table ->
- le rsultat
- vrification
Lordre SQL
SELECT LAST_INSERT_ID()
permet de connatre la dernire valeur insre dans le champ ID de la table. Elle est mettre aprs l'insertion. C'est une
diffrence avec les SGBD [Firebird] et [Postgres] o on demandait la valeur de la cl primaire de la personne ajoute avant
l'insertion. Nous lutiliserons dans le fichier [personnes-mysql.xml] qui rassemble les ordres SQL mis sur la base de donnes.
4.2
Pour dvelopper les couches [dao] et [service] de notre application avec la base de donnes MySQL, nous utiliserons le projet
Eclipse [spring-mvc-40] suivant :
56/73

Dossier [src]
Tous les fichiers ayant [mysql] dans leur nom ont pu subir ou non une modification vis vis des versions Firebird et Postgres. Dans
ce qui suit, nous dcrivons ceux qui ont t modifis.
Dossier [database]
Ce dossier contient le script de cration de la base de donnes MySQL des personnes :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
#
#
#
#
#
EMS MySQL Manager Lite 3.2.0.1

--------------------------------------Host
: localhost
Port
: 3306
Database : dbpersonnes
SET FOREIGN_KEY_CHECKS=0;
CREATE DATABASE `dbpersonnes`
CHARACTER SET 'latin1'
COLLATE 'latin1_swedish_ci';
USE `dbpersonnes`;
#
# Structure for the `personnes` table :
57/73
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
#
CREATE TABLE `personnes` (
ÌD` int(11) NOT NULL auto_increment,
`VERSION` int(11) NOT NULL default '0',
`NOM` varchar(30) NOT NULL default '',
`PRENOM` varchar(30) NOT NULL default '',
`DATENAISSANCE` date NOT NULL default '0000-00-00',
`MARIE` tinyint(4) NOT NULL default '0',
`NBENFANTS` int(11) NOT NULL default '0',
PRIMARY KEY (ÌD`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
#
# Data for the `personnes` table
#
(LIMIT 0,500)
INSERT INTO `personnes` (ÌD`, `VERSION`, `NOM`, `PRENOM`, `DATENAISSANCE`, `MARIE`, `NBENFANTS`)
VALUES
36.
(1,1,'Major','Joachim','1984-01-13',1,2),
37.
(2,1,'Humbort','Mlanie','1985-01-12',0,1),
38.
(3,1,'Lemarchand','Charles','1986-01-01',0,0);
39.
40. COMMIT;
Dossier [lib]
On notera la prsence du pilote jdbc du SGBD MySQL. Toutes ces archives font partie du Classpath du projet Eclipse.
Dossier [dist]
4.3

La couche [dao]
58/73

Le fichier de mapping [personne-mysql.xml] est le suivant :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.

<!DOCTYPE sqlMap
<sqlMap>
</resultMap>
insert into
PERSONNES(VERSION, NOM, PRENOM, DATENAISSANCE, MARIE, NBENFANTS)
VALUES(#version#, #nom#, #prenom#, #dateNaissance#, #marie#,
#nbEnfants#)
select LAST_INSERT_ID() as value
</selectKey>
</insert>
<delete id="Personne.deleteOne" parameterClass="int"> delete FROM PERSONNES WHERE

<select id="Personne.getNextId" resultClass="int">select
LAST_INSERT_ID()</select>
</sqlMap>
lordre SQL " Personne.insertOne " a chang lignes 29-37 :
59/73
l'ordre SQL d'insertion est excut avant l'ordre SELECT qui va permettre de rcuprer la valeur de la cl primaire
de la ligne insre
l'ordre SQL d'insertion n'a pas de valeur pour la colonne ID de la table [PERSONNES]
Cela reflte l'exemple d'insertion que nous avons comment page 56.
On notera qu'il y a peut-tre l une source possible de problmes entre threads concurrents. Imaginons deux threads Th1
et Th2 qui font une insertion en mme temps. Il y a au total quatre ordres SQL mettre. Supposons qu'ils soient faits
dans l'ordre suivant :
1. insertion I1 de Th1
2. insertion I2 de Th2
3. select S1 de Th1
4. select S2 de Th2
En 3, Th1 rcupre la cl primaire gnre lors de la dernire insertion, donc celle de Th2 et non la sienne. Je ne sais pas si
la mthode [insert] d'iBATIS est protge pour ce cas de figure. Nous allons supposer qu'elle le gre proprement. Si ce
n'tait pas le cas, il nous faudrait driver la classe dimplmentation [DaoImplCommon] de la couche [dao] en une classe
[DaoImplMySQL] o la mthode [insertPersonne] serait synchronise. Ceci ne rsoudrait le problme que pour les
threads de notre application. Si ci-dessus, Th1 et Th2 sont des threads de deux applications diffrentes, il faudrait alors
rsoudre le problme la fois avec des transactions et un niveau d'tanchit adquat (isolation level) entre transactions.
Le niveau [serializable] dans lequel les transactions sont excutes comme si elles s'excutaient squentiellement serait
appropri.
On notera que ce problme n'existe pas avec les SGBD Firebird et Postgres qui eux font le SELECT avant l'INSERT. Si
on a par exemple la squence :
1.
2.
3.
4.
select S1 de Th1
select S2 de Th2
insertion I1 de Th1
insertion I2 de Th2
Aux tapes 1 et 2, Th1 et Th2 rcuprent des valeurs de cl primaire auprs du mme gnrateur. Cette opration est
normalement atomique, et Th1 et Th2 vont rcuprer deux valeurs diffrentes. Si l'opration n'tait pas atomique, et que
Th1 et Th2 rcupraient deux valeurs identiques, l'insertion faite en 4 par Th2 chouerait pour cause de doublon de cl
primaire. C'est une erreur tout fait rcuprable et Th2 peut retenter l'insertion.
On va laisser l'opration " Personne.insertOne " telle qu'elle est actuellement dans le fichier [personnes-mysql.xml] mais le
lecteur doit avoir conscience qu'il y a l potentiellement un problme.
La classe dimplmentation [DaoImplCommon] de la couche [dao] est celle des deux versions prcdentes.
La configuration de la couche [dao] a t adapte au SGBD [MySQL]. Ainsi, le fichier de configuration [spring-config-test-daomysql.xml] est-il le suivant :
3. <beans>
4.
5.
6.
7.
8.
<value>com.mysql.jdbc.Driver</value>
9.
</property>
10.
11.
<value>jdbc:mysql://localhost/dbpersonnes</value>
12.
</property>
13.
14.
<value>root</value>
15.
</property>
16.
17.
<value></value>
18.
</property>
19. </bean>
22.
23.
24.
25.
</property>
26.
27.
<value>classpath:sql-map-config-mysql.xml</value>
28.
</property>
60/73
29.
30.
31.
32.
33.
34.
35.
</bean>
</property>
</bean>
36.</beans>
lignes 5-19 : le bean [dataSource] dsigne maintenant la base [MySQL] [dbpersonnes] dont ladministrateur est [root] sans
mot de passe. Le lecteur modifiera cette configuration selon son propre environnement.
4.4
- couche [dao]
- couche [service]
4.5
Pour tester lapplication web avec le SGBD [MySQL], nous construisons un projet Eclipse [spring-mvc-40B] de faon analogue
celle utilise pour construire le projet [spring-mvc-38B] avec la base Firebird (cf page 39).
Le SGBD MySQL est lanc. Le contenu de la table [PERSONNES] est alors le suivant :
61/73
5 Spring MVC dans une architecture 3tier Exemple 5 SQL Server

Express
5.1
La base de donnes SQL Server Express
Dans cette version, nous allons installer la liste des personnes dans une table de base de donnes SQL Server Express 2005
disponible l'url [http://msdn.microsoft.com/vstudio/express/sql/]. Dans ce qui suit, les copies dcran proviennent du client
EMS Manager Lite pour SQL Server Express [http://www.sqlmanager.net/fr/products/mssql/manager], un client
dadministration gratuit du SGBD SQL Server Express.
62/73
suivants :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CREATE TABLE [dbo].[PERSONNES] (

[ID] int IDENTITY(1, 1) NOT NULL,
[VERSION] int NOT NULL,
[NOM] varchar(30) COLLATE French_CI_AS NOT NULL,
[PRENOM] varchar(30) COLLATE French_CI_AS NOT NULL,
[DATENAISSANCE] datetime NOT NULL,
[MARIE] tinyint NOT NULL,
[NBENFANTS] tinyint NOT NULL,
PRIMARY KEY CLUSTERED ([ID]),
CONSTRAINT [PERSONNES_ck_NOM] CHECK ([NOM]<>''),
CONSTRAINT [PERSONNES_ck_PRENOM] CHECK ([PRENOM]<>''),
CONSTRAINT [PERSONNES_ck_NBENFANTS] CHECK ([NBENFANTS]>=(0))
)
ON [PRIMARY]
GO
ligne 2 : la cl primaire [ID] est de type entier. L'attribut IDENTITY indique que si on insre une ligne sans valeur pour
la colonne ID de la table, SQL Express gnrera lui-mme un nombre entier pour cette colonne. Dans IDENTITY(1, 1),
le premier paramtre est la premire valeur possible pour la cl primaire, le second, l'incrment utilis dans la gnration
des nombres.
Nous savons que lors de l'insertion d'un objet [Personne] par notre couche [dao], le champ [id] de cet objet est gal -1 avant
l'insertion et a une valeur diffrente de -1 ensuite, cette valeur tant la cl primaire affecte la nouvelle ligne insre dans la table
[PERSONNES]. Voyons sur un exemple comment nous allons pouvoir connatre cette valeur.
63/73
- on excute l'ordre d'insertion ci-dessus (F12). On notera qu'on ne donne pas de valeur
au champ ID ->
- on excute l'ordre SELECT ci-dessus

pour connatre la dernire valeur
insre dans le champ ID de la table ->
- le rsultat
- vrification
Lordre SQL
SELECT @@IDENTITY
permet de connatre la dernire valeur insre dans le champ ID de la table. Elle est mettre aprs l'insertion. C'est une
diffrence avec les SGBD [Firebird] et [Postgres] o on demandait la valeur de la cl primaire de la personne ajoute avant
l'insertion, mais c'est analogue la gnration de cl primaire du SGBD MySQL. Nous lutiliserons dans le fichier [personnessqlexpress.xml] qui rassemble les ordres SQL mis sur la base de donnes.
5.2
Pour dvelopper les couches [dao] et [service] de notre application avec la base de donnes[SQL Server Express], nous utiliserons le
projet Eclipse [spring-mvc-41] suivant :

Dossier [src]
64/73
Tous les fichiers ayant [sqlexpress] dans leur nom ont pu subir ou non une modification vis vis des versions Firebird, Postgres et
MySQL. Dans ce qui suit, nous ne dcrivons que ceux qui ont t modifis.
Dossier [database]
Ce dossier contient le script de cration de la base de donnes SQL Express des personnes :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
-----
SQL Manager 2005 Lite for SQL Server (2.2.0.1)

--------------------------------------Host
: (local)\SQLEXPRESS
Database : dbpersonnes
--- Structure for table PERSONNES :

-CREATE TABLE [dbo].[PERSONNES] (
[ID] int IDENTITY(1, 1) NOT NULL,
[VERSION] int NOT NULL,
[NOM] varchar(30) COLLATE French_CI_AS NOT NULL,
[PRENOM] varchar(30) COLLATE French_CI_AS NOT NULL,
[DATENAISSANCE] datetime NOT NULL,
[MARIE] tinyint NOT NULL,
[NBENFANTS] tinyint NOT NULL,
CONSTRAINT [PERSONNES_ck_NBENFANTS] CHECK ([NBENFANTS]>=(0)),
CONSTRAINT [PERSONNES_ck_NOM] CHECK ([NOM]<>''),
CONSTRAINT [PERSONNES_ck_PRENOM] CHECK ([PRENOM]<>'')
)
ON [PRIMARY]
GO
--- Data for table PERSONNES
--
(LIMIT 0,500)
SET IDENTITY_INSERT [dbo].[PERSONNES] ON

GO
INSERT INTO [dbo].[PERSONNES] ([ID], [VERSION], [NOM], [PRENOM], [DATENAISSANCE], [MARIE],

[NBENFANTS])
34. VALUES
35.
(1, 1, 'Major', 'Joachim', '19541113', 1, 2)
36. GO
37.
38. INSERT INTO [dbo].[PERSONNES] ([ID], [VERSION], [NOM], [PRENOM], [DATENAISSANCE], [MARIE],
[NBENFANTS])
39. VALUES
40.
(2, 1, 'Humbort', 'Mlanie', '19850212', 0, 1)
41. GO
42.
43. INSERT INTO [dbo].[PERSONNES] ([ID], [VERSION], [NOM], [PRENOM], [DATENAISSANCE], [MARIE],
[NBENFANTS])
44. VALUES
45.
(3, 1, 'Lemarchand', 'Charles', '19860301', 0, 0)
65/73
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
GO
SET IDENTITY_INSERT [dbo].[PERSONNES] OFF
GO
--- Definition for indices :
-ALTER TABLE [dbo].[PERSONNES]
ADD PRIMARY KEY CLUSTERED ([ID])
WITH (
PAD_INDEX = OFF,
IGNORE_DUP_KEY = OFF,
STATISTICS_NORECOMPUTE = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY]
GO
Dossier [lib]
On notera la prsence du pilote jdbc [sqljdbc.jar] du SGBD [Sql Server Express]. Toutes ces archives font partie du Classpath du
projet Eclipse.
Dossier [dist]
5.3

La couche [dao]
66/73

Le fichier de mapping [personne-sqlexpress.xml] est le suivant :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.

<!DOCTYPE sqlMap
<sqlMap>
</resultMap>
insert into
PERSONNES(VERSION, NOM, PRENOM, DATENAISSANCE, MARIE, NBENFANTS)
VALUES(#version#, #nom#, #prenom#, #dateNaissance#, #marie#,
#nbEnfants#)
select @@IDENTITY as value
</selectKey>
</insert>
<delete id="Personne.deleteOne" parameterClass="int"> delete FROM PERSONNES WHERE

<select id="Personne.getNextId" resultClass="int">select
LAST_INSERT_ID()</select>
</sqlMap>

lordre SQL " Personne.insertOne " a chang lignes 29-37 :
l'ordre SQL d'insertion est excut avant l'ordre SELECT qui va permettre de rcuprer la valeur de la cl primaire
de la ligne insre
67/73
l'ordre SQL d'insertion n'a pas de valeur pour la colonne ID de la table [PERSONNES]
Cela reflte l'exemple d'insertion que nous avons comment page 63. A noter, qu'on retrouve ici le problme d'insertions
simultanes par des threads diffrents dcrit pour MySQL au paragraphe 4.3, page 60.
La classe dimplmentation [DaoImplCommon] de la couche [dao] est celle des trois versions prcdentes.
La configuration de la couche [dao] a t adapte au SGBD [SQL Express]. Ainsi, le fichier de configuration [spring-config-testdao-sqlexpress.xml] est-il le suivant :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
<?xml version="1.0" encoding="ISO_8859-1"?>

<!DOCTYPE beans SYSTEM "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<value>com.microsoft.sqlserver.jdbc.SQLServerDriver</value>
</property>
<value>jdbc:sqlserver://localhost\\SQLEXPRESS:4000;databaseName=dbpersonnes</value>
</property>
<value>sa</value>
</property>
<value>msde</value>
</property>
</bean>

<bean id="sqlMapClient"
</property>
<value>classpath:sql-map-config-sqlexpress.xml</value>
</property>
</bean>
</property>
</bean>
</beans>
lignes 5-19 : le bean [dataSource] dsigne maintenant la base [SQL Express] [dbpersonnes] dont ladministrateur est [sa]
avec le mot de passe [msde]. Le lecteur modifiera cette configuration selon son propre environnement.
La ligne 11 mrite des explications :

<value>jdbc:sqlserver://localhost\\SQLEXPRESS:4000;databaseName=dbpersonnes</value>
//localhost : indique que le serveur SQL Express est sur la mme machine que notre application Java
\\SQLEXPRESS : est le nom d'une instance de SQL Server. Il semble que plusieurs instances peuvent s'excuter en
mme temps. Il semble donc logique de nommer l'instance laquelle on s'adresse. Ce nom peut tre obtenu grce [SQL
Server Configuration Manager] install normalement en mme temps que SQL Express :
68/73
4000 : port d'coute de SQL Express. Cela est dpendant de la configuration du serveur. Par dfaut, il travaille avec des
ports dynamiques, donc pas connus l'avance. On ne prcise alors pas de port dans l'url JDBC. Ici, nous avons travaill
avec un port fixe, le port 4000. Cela s'obtient par configuration :
- [clic droit sur TCP/IP -> Proprits] ->
- on laisse les champs [TCP Dynamic Ports] vides

- on met les champs [TCP Port] 4000
l'attribut dataBaseName fixe la base de donnes avec laquelle on veut travailler. C'est celle qui a t cre avec le client
EMS :
5.4
- couche [dao]
- couche [service]
69/73
5.5
Pour tester lapplication web avec le SGBD [SQL Server Express], nous construisons un projet Eclipse [spring-mvc-41B] de faon
analogue celle utilise pour construire le projet [spring-mvc-38B] avec la base Firebird (cf page 39).
Le SGBD SQL server Express est lanc. Le contenu de la table [PERSONNES] est alors le suivant :
70/73
6 Conclusion
Rappelons le but de cet article. Dans l'article qui prcdait, nous avions mis en oeuvre Spring MVC dans une architecture 3tier
[web, metier, dao] sur un exemple basique de gestion dune liste de personnes.
utilisateur
DispatcherServlet
1
Couche service
[service]
2
3
Controller
4
View
Couche d'accs
aux donnes
[dao]
Donnes
Modle Map
6
Dans cette version 1, la liste des personnes tait maintenue en mmoire et disparaissait au dchargement de lapplication web. Dans
les quatre nouvelles versions tudies ici, la liste des personnes est maintenue dans une table de base de donnes. Nous avons utilis
quatre SGBD diffrents : Firebird, Postgres, MySQL et SQL Server Express. Nous n'avons dvelopp que les seules couches
[service] et [dao], la couche [web] restant celle dveloppe pour la version 1.
Ce que nous avons voulu montrer dans cet article, c'est l'apport de Spring pour la construction des couches [dao] et [service]. Grce
l'intgration de Spring avec iBATIS, nous avons pu construire quatre versions qui ne diffrent que par leurs fichiers de
configuration. La mme classe [DaoImplCommon] a t utilise pour implmenter la couche [dao] dans les quatre versions. Pour
grer un problme spcifique au SGBD Firebird, nous avons t amens driver cette classe mais pas la modifier.
Enfin, nous avons montr comment Spring nous permettait de grer les transactions de faon dclarative au niveau de la couche
[service].
7 Le code de l'article
Comme pour les prcdents articles, le lecteur trouvera le code des exemples de ce document sous la forme d'un fichier zipp sur le
site de l'article. Les rgles de dploiement du fichier zipp sont relire dans l'article 1. Une fois un projet import dans [Eclipse] :
copier le contenu du dossier [lib] du zip dans le dossier [WEB-INF/lib] du projet
s'assurer que le dossier [work] existe sinon le crer : [clic droit sur projet / Projet Tomcat / Crer le dossier work]
nettoyer le projet [Project / clean / clean selected projects]

Pour rejouer les tests, le lecteur devra adapter la configuration du [DataSource] trouv dans les diffrents fichiers de
configuration son propre environnement. Cet objet renseigne :
1. le nom de classe du pilote JDBC du SGBD utilis
2. l'url de la base de donnes exploiter
3. le propritaire des connexions qui sont ouvertes sur la base
4. le mot de passe de ce dernier.
Les informations 2 4 sont dpendantes de l'environnement utilis pour les tests.
Le code est livr sous la forme d'un zip contenant les dossiers suivants :
Le dossier [lib] rassemble les archives utilises par les diffrents projets [mvc-xx, mvc-xxB] :
71/73
Les dossiers [lib] des diffrents projets ont t eux vids afin de diminuer la taille du zip. Il faudra donc aller chercher les archives
ncessaires un projet dans le dossier [lib] ci-dessus. Dans les dossiers [lib] des projets web [mvc-xxB], on a laiss les archives des
couches [dao], [service] et [web] de l'application construite par les projets associs [mvc-xx] :
72/73
Table des matires

1RAPPELS..................................................................................................................................................................................... 2
2SPRING MVC DANS UNE ARCHITECTURE 3TIER EXEMPLE 2 - FIREBIRD......................................................... 2
2.1LA BASE DE DONNES FIREBIRD.......................................................................................................................................................2
2.2LE PROJET ECLIPSE DES COUCHES [DAO] ET [SERVICE]..................................................................................................................... 4
2.3LA COUCHE [DAO]..........................................................................................................................................................................6
2.3.1LES COMPOSANTES DE LA COUCHE [DAO]......................................................................................................................................... 6
2.3.2LA COUCHE DACCS AUX DONNES [IBATIS]................................................................................................................................ 8
2.3.3LA CLASSE [DAOIMPLCOMMON].................................................................................................................................................. 14
2.4TESTS DE LA COUCHE [DAO]..........................................................................................................................................................20
2.4.1TESTS DE L'IMPLMENTATION [DAOIMPLCOMMON]......................................................................................................................... 20
2.4.2LA CLASSE [DAOIMPLFIREBIRD]...................................................................................................................................................28
2.4.3TESTS DE L'IMPLMENTATION [DAOIMPLFIREBIRD]..........................................................................................................................29
2.5LA COUCHE [SERVICE]..................................................................................................................................................................31
2.5.1LES COMPOSANTES DE LA COUCHE [SERVICE].................................................................................................................................. 31
2.5.2CONFIGURATION DE LA COUCHE [SERVICE]..................................................................................................................................... 32
2.6TESTS DE LA COUCHE [SERVICE]....................................................................................................................................................36
2.7LA COUCHE [WEB]....................................................................................................................................................................... 39
2.8CONCLUSION................................................................................................................................................................................46
3SPRING MVC DANS UNE ARCHITECTURE 3TIER EXEMPLE 4 - POSTGRES..................................................... 47
3.1LA BASE DE DONNES POSTGRES................................................................................................................................................... 47
3.2LE PROJET ECLIPSE DES COUCHES [DAO] ET [SERVICE]................................................................................................................... 49
3.3LA COUCHE [DAO]........................................................................................................................................................................51
3.4LES TESTS DES COUCHES [DAO] ET [SERVICE]................................................................................................................................. 53
3.5TESTS DE LAPPLICATION [WEB].................................................................................................................................................... 54
4SPRING MVC DANS UNE ARCHITECTURE 3TIER EXEMPLE 4 - MYSQL............................................................55
4.1LA BASE DE DONNES MYSQL.....................................................................................................................................................55
4.3LA COUCHE [DAO]........................................................................................................................................................................58
5SPRING MVC DANS UNE ARCHITECTURE 3TIER EXEMPLE 5 SQL SERVER EXPRESS..............................62
5.1LA BASE DE DONNES SQL SERVER EXPRESS................................................................................................................................ 62
5.3LA COUCHE [DAO]........................................................................................................................................................................66
6CONCLUSION.......................................................................................................................................................................... 71
7LE CODE DE L'ARTICLE...................................................................................................................................................... 71
73/73

Spring MVC 5

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Spring MVC 5

Загружено:

Авторское право:

Доступные форматы

Spring MVC par l'exemple

serge.tahe@istia.univ-angers.fr, avril 2006

springmvc - partie5, ST universit dAngers

Spring MVC par l'exemple partie 1 : [http://tahe.developpez.com/java/springmvc-part1]

SQL Manager Lite pour Firebird :

SQL Manager Lite pour Postgres :

SQL Manager Lite pour MySQL :

SQL Server Management Studio Express :

SQL Manager Lite pour SQL Server Express:

2 Spring MVC dans une architecture 3tier Exemple 2 - Firebird

La base de donnes Firebird

springmvc - partie5, ST universit dAngers

CREATE TABLE PERSONNES (

CHK_PRENOM_PERSONNES check (PRENOM<>'');

ALTER TABLE PERSONNES ADD CONSTRAINT PK_PERSONNES PRIMARY KEY (ID);

La table [PERSONNES] pourrait avoir le contenu suivant :

springmvc - partie5, ST universit dAngers

- le gnrateur a actuellement la valeur 96

- double-cliquer sur [GEN_PERSONNES_ID]

- mettons lordre SQL ci-dessus (F12) ->

Le projet Eclipse des couches [dao] et [service]

Ce dossier contient les codes source des couches [dao] et [service] :

On y trouve diffrents paquetages :

[istia.st.springmvc.personnes.dao] : contient la couche [dao]

[istia.st.springmvc.personnes.entites] : contient la classe [Personne]

[istia.st.springmvc.personnes.service] : contient la classe [service]

[istia.st.springmvc.personnes.tests] : contient les tests JUnit des couches [dao] et [service]

[dbpersonnes.gdb] est la base de donnes.

[personnes-dao.jar] : archive de la couche [dao]

La couche [dao] est constitue des classes et interfaces suivantes :

[IDao] est linterface prsente par la couche [dao]

Linterface [IDao] est la suivante :

linterface a les mmes quatre mthodes que dans la version prcdente.

La classe [DaoImplCommon] implmentant cette interface sera la suivante :

springmvc - partie5, ST universit dAngers

// vrification validit d'une personne

La couche daccs aux donnes [iBATIS]

springmvc - partie5, ST universit dAngers

springmvc - partie5, ST universit dAngers

Couche d'accs aux donnes

Couche d'accs aux donnes

Une squence typique dactions avec cet objet est la suivante :

demander une connexion un pool de connexions

springmvc - partie5, ST universit dAngers

Nous progressons... Notre fichier de configuration se prcise et devient :

ouvrir une connexion

le nom du pilote JDBC utiliser initialis avec [setDriverClassName]

Le fichier de configuration de notre couche [dao] pourra tre le suivant :

lignes 7-9 : le nom du pilote JDBC du SGBD Firebird

<?xml version="1.0" encoding="UTF-8" ?>

ce fichier doit avoir <sqlMapConfig> comme balise racine (lignes 6 et 8)

<?xml version="1.0" encoding="UTF-8" ?>

springmvc - partie5, ST universit dAngers

le fichier doit avoir <sqlMap> comme balise racine (lignes 7 et 45)

Revenons sur larchitecture daccs aux donnes :

Couche d'accs aux donnes

Couche d'accs aux donnes

La classe [DaoImplCommon] est la suivante :

public class DaoImplCommon extends SqlMapClientDaoSupport implements

notre type propritaire [DaoException]

le type Spring [DataAccessException]

Il implmente linterface [SqlMapClientOperations] suivante :

[statementName] : lidentifiant (id) de lordre [select] dans le fichier de configuration