Discussion :

[offsh]

Hibernate 3.2.x
spring 2.5.x
weblogic 10

cache de 2nd niveau : ehCache
transaction sur enregistrement : @Transactional(propagation = Propagation.REQUIRED, readOnly = false, rollbackFor = Exception.class)


J'ouvre deux navigateurs je me connecte avec 2 user différents.
Je vais sur la page de modification de l'objet A (id12) sur chaque navigateur.
Je sauvegarde une modification sur l'un (modification prise en compte).
Je sauvegarde une modification sur l'autre (modification prise en compte).
<Je n'ai pas trouvé mieux comme test :/>
Vu que l'objet à été modifié, je souhaiterai que dans le cas de la deuxieme sauvegarde il me remonte une exception.

J'ai lu tout les docs sur la gestion optimiste, je pense avoir tout bien configuré, mais je peux toujours ecraser l'enregistrement précédent....

Avez vous une piste ?

[tchize_]

D'abord, il faut savoir si hibernate recharge l'objet à chauqe requete ou si tu garde l'objet dans la session entre tes 2 requetes (pour la meme session). Dans le premier cas, c'est à toi de détecter que l'objet à été modifié, car pour hibernate il n'y aura pas de modif concurrente sur tu fait load(), modification, saveOrUpdate() dans le même request.

Par contre, si tu fait

GET
load()
send response
POST
reattach
modification
saveOrUpdate()
send response

Il me semble que tu peux forcer hibernate à remonter une exception lors du persist en utilisant le versioning de tes objets. Perso je l'ai jamais utilisé, mais si je ne me trompe pas, çà peut servir à çà, entre autres. C'est en pratique une colonne supplémentaire avec un numéro de version.

[offsh]

Je vais tester en rajoutant un timestamp pour le versionning, mais je viens de me rendre compte d'une chose dans la doc.

http://www.hibernate.org/hib_docs/re...l/mapping.html
chap 5.1.3

optimistic-lock="none|version|dirty|all"

optimistic-lock (optionnel, par défaut = version) : Détermine la stratégie de verrou optimiste.

version vérifie les colonnes version/timestamp

all vérifie toutes les colonnes

dirty vérifie les colonnes modifiées, permettant des updates concurrents

none pas de verrouillage optimiste

Par défaut je me trouve en mode version mais n'ayant pas de <timestamp> ou de <version> il doit se comporter comme si il était en 'none'.

Je confirme sous peu...

[offsh]

Apres ajout d'un timestamp, aucune exception ne remonte...

Pourtant dans AbstractEntityPersister.update(..) j'ai bien useVersion à 'true' .

J'ai le log suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
26 août 2008 14:46:05 DEBUG org.hibernate.persister.entity.AbstractEntityPersister - Updating entity: [ch.vd.dfin.tao.is.core.model.liste.impl.ListeImpl#1008]
26 août 2008 14:46:06 DEBUG org.hibernate.persister.entity.AbstractEntityPersister - Existing version: 2008-08-26 14:18:10.423 -> New version: 2008-08-26 14:45:33.421

=========
Question :

(Il s'apprete donc a comparer la date que j'avais dans mon objet en cache avec la date de mon objet a sauver. ) Pourquoi ne compare t-il pas la date que j'ai en en cache avec la date que j'ai en base ?

========
Pour ce qui est de la gestion des sessions.. Je suis en mode 'session-per-request'. De fait mes deux objets sont chargés par des sessions differentes.. d'apres la doc utiliser le lock-mode ="version" est suffisant.

[offsh]

Je met mes questions en standby...
Je viens de voir au fin fond du controleur qu'on recharger l'objet juste avant de l'enregistrer puis on remplace par ce qui à été saisie dans le formulaire.....
Vivement une formation spring mvc...

[offsh]

donc en fait l'ajout du <timestamp /> suffisait bien.

Un rechargement de mon objet était caché dans un service...