Reprise du message précédent :
Dite les gens, vous faites comment pour gérer les accès concurrent en sauvegarde dans une DB?
Pour l'instant je mets des champs lastModification un peu partout, ca marche pas mal mais ca me gave mnt.
 
Par exemple, on a une appli web basique avec des fiches sauver dans une DB.
La secrétaire A commence à éditer la fiche Z, pendant qu'elle tape et avant qu'elle clique sur sauver, sa collège, la secrétaire B, ouvre justement la meme fiche Z.
 
On n'a pas le droit de bloquer les fiches et dire à B "non tu peux pas ouvrir la fiche Z car qqun l'a deja ouverte" ou "tu peux l'ouvrir mais pas la modifier", sinon ca serai trop facile.
 
La secrétaire A à fini ses modifications et sauve la ficher Z.
Lorsque la secrétaire B veut sauver ses modifs (apres A), un message la prévient que qqun à modifié la fiche Z, lui dit gentiment que ses modifications sont perdu    et que la fiche Z va se rafraîchir.
 
Pour faire ca, j'ai mis un champs timestamp LastModification à la class fiche, et juste avant de sauver, dans la même transaction, je regarde si lastmodification de mon objet en mémoire correspond bien à celui dans la DB. Si oui, je sauve, sinon, qqun à modifié entre temps, je sauvegarde pas et je rafraîchis.
 
J'ai testé avec 5 utilisateurs dans la meme piece en cliquant à 5 en meme temps sur sauver, ca marche bien (enfin ca en envoie 4 sur les roses mais c'est normal)
 
Mais j'ai besoin de mettre un champs timestamp dans chaque class et à la fin c'est pas très pratique.
 
y'a pas qqch de plus simple?
 
merci  

bon je reformule ma question

Est ce que qqun sait comment faire en sorte que ant compile de la même façon que eclipse ?

Les classes générées par eclipse et ant sont en effet différentes, et ça me pose des problèmes

j'ai tenté de spécifier compile="org.eclipse.jdt.core.JDTCompilerAdapter" mais j'ai un probleme de class not found

 
Optimistic locking   Parce que là, c'est un peu bricolage ton truc non ?
 

 
J'aurais plutôt tendance à vouloir que mon IDE compile comme mon outil de build, pas l'inverse.
 

 
pas quand l'outil de build compile par défaut dans une version ancestrale

bon j'ai trouvé, sur google, il faut lancer ant avec la jre utilisée par eclipse, et préciser <property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter" />

Pour ma culture perso, ça impose la présence d'Eclipse sur tout poste qui va compiler ça non ? Quid du switch entre IDE, d'un serveur de build / intégration ? Y'a pas moyen de spécifier une version d'un compilo standard qui marcherais dans ton cas ?
(et je pensais dans ma première réponse que tu reformulais le post de sixpack juste avant le tien, j'ai aps retrouvé à quoi tu faisait référence)

c'est que le build par ant posait des problemes au niveau des accents
Donc oui j'aurais pu le régler dans un sens ou l'autre mais là tout de suite, j'étais sur qu'avec éclipse ça fonctionnait correctement

Ant est censé gicler quand la nouvelle version avec mavenisée et springuisée passera en prod.
Les process sont à des années lumières d'utiliser des serveurs de build ici.
Déjà gicler ant c'est un grand pas en avant et c'est pas le genre d'endroit ou chacun va installer son propre ide.

propertie "encoding" sur le tag javac ?  
http://ant.apache.org/manual/Tasks/javac.html
 

j'ai eu besoin de cette doc pour mettre le niveau target et source en 1.5
je fais un test, je vais peut être avoir besoin de remettre encoding

 
gicler ant pour utiliser eclipse, un pas en avant ?
 

Je pense qu'il parlait de gicler Ant vers Maven

J'arrive un peu tard mais perso ca me choque pas ton système si les contraintes d'utilisation de l'appli sont fixées (= le premier à sauvegarder nique tous les autres).
Dans l'absolu, le mieux serait d'avoir un systeme de lock et que le premier à accéder aux données les lock en écriture, mais tu dis que pas possible donc bon.
Pour ta détection, une date ou une version ca m'a l'air classique, j'vois pas trop comment on pourrait faire d'autre (mais si qqun sait...).
Après tu peux aussi etre user-friendly et faire un méga truc qui détecte que quelqu'un modifie les données, remonte ca a ton appli et propose pour chaque champ le choix entre la nouvelle valeur en base et la valeur déjà saisie dans la page. Oh yeah.

 
http://download.oracle.com/javase/ [...] /Lock.html

le lock il faut le mettre en attribut static de la classe, si tu as plusieurs instance

ouais, bonne idée, bloque les threads de requetes http pendant 4heures, ton serveur a que ça a foutre

ouais t'as rien compris quoi  

t'as édité cochon
(bon ou alors j'avais pas vu que tu appelais *try* lock )
 
Cela dit, ça va pas l'aider, si ce bout de code est dans une servlet (ou apparenté)...appelé au moment de sauver. alors qu'idéalement la secrétaire elle veut voir le "warning" avant/pendant qu'elle commence a bosser, pas apres avoir passer 2h a remplir un formulaire.

non j'ai pas édité, tu veux dire if (lock.tryLock()) {

ça faut voir avec sixpack
moi je trouve ça con de permettre l'édition à la secretaire B si le fichier est locké, donc je ferais un test if(lock.tryLock()) déjà à ce moment là.

Ou alors tester le statut le statut périodiquement avec un appel ajax et afficher le lien d'édition quand il est débloqué, et donc relocker pour B.

quoique c'est naze car si elle scotche en édition et oublie qu'elle était sur cette page pendant 15 minutes et qu'elle enregistre pas, ça bloque tout pour rien.
C'est ce qui se passe quand qqun bloque un fichier excell ou word sur le réseau, c'est hyper chiant.

Donc je garderais juste le jetage niveau action/servlet à la sauvegarde

On est presque vendredi, je réfléchissais à un truc bête... C'est à propos d'erreur handling.
 
Une entreprise donnée diffuse un soft dans la nature. Le seul moyen d'avoir un retour quant aux bug rencontrés, c'est que les utilisateurs informent eux-même (idéalement remplissent le bugtracker) la boîte.
 
Imaginons - parce que je ne sais pas si ça existe - un mécanisme tout bête à la racine dudit soft, genre un bourrin try / catch all dans le main, donc l'objectif serait d'intercepter tout ce qui ne l'est pas déjà ailleurs, et de l'envoyer à l'entreprise émettrice du soft. Déjà, bone / mauvaise idée en soi ? Discuss.
 
Évidemment, alimenter directement le bugtraker de cette manière serait suicidaire (bug dupliqués, fouilouillou le nombre d'entrées...). On partirait donc sur un serveur dédié à cette "application" (pas l'application dans la nature, mais cette méthode de collecte des traces), auquel on ajouterait des connecteurs vers le bugtracker. Le workflow serait le suivant : l'équipe de dev consulte le serveur de collecte, et pour un bug identifié, à la possibilité de créer une anno avec les infos pré renseignées.
 
Je me lance, c'est une mauvaise idée, ça existe déjà ?

Bah ouais, ça se fait, mais évidemment t'injects pas ça dans ton bugtracker principal mais dans le tracker de ton équipe de support.
 
Un bon départ c'est d'avoir un bignou qui prépare un fichier zip avec des infos sur le system, des logs, tout ce dont ton équipe de support va avoir besoin pour solutionner le probleme de l'utilisateur. Et s'il se trouve que le probleme est un bug du software, ils remontent le bug dans le tracker principal.
 
Apres, si t'as un truc a base de listener qui fait tout automatiquement, bien, mais à priori, je laisserais la prise en charge de l'envoi à l'utilisateur (en lui facilitant la tache - juste un bouton à cliquer) sinon clairement tu vas te retrouver avec 2073 paquets pour le meme probleme, vu qu'ils vont essayer 2072 fois le meme truc avant de te contacter.

 
"Ça se fait" ça existe, ou tout le monde se refade une solution custom ? L'idée est de savoir si ça pourrait constituer un bon projet à mettre à dispo.
 
 

 
On est d'accord, et rien qu'éthiquement, je me vois mal envoyer les infos sans que l'utilisateur ne le sache.
 

je tenterais d'utiliser des aspects plutot que des try catchs intrusifs

Je ne connais pas de solution pré-existante, mais j'ai jamais cherché non plus.
Entre les libs de log, les outils de monitoring et autres, y'a ptet moyen de sortir un truc valable qui soit réutilisable, mais c'est sans doute pas le truc le plus évident a généraliser.
 

 
J'ai jamais fait d'AOP, ça serait l'occasion. Du peu que j'ai vu par contre, ça m'a l'air un peu contraignant dans le cas d'une lib diffusée : dépendance au compilo pour Aspectj et valable uniquement sur ce qui sort de SpringFactory pour Spring-AOC. Quitte à partir sur ce type de projet, j'aimerais autant que les utilisateurs n'aient qu'à inclure une lib, ajouter une annotation et ne rien changer d'autre (i.e. pas changer de compilo ou ajouter un framework).
 
Ceci dit, j'ai peut-être mal compris les contraintes, ou tu connais peut-être une autre solution plus adaptée...
 

 
regarde du côté de l'instrumentation et du loadtime weaving
 
En gros ça permet de springuiser nimporte quelle classe.
J'avais fait ça pour rendre transactionnelles des Actions Struts, en utilisant même des annontation @transactional, et injecter des beans dedans par @autowired. C'est plus pratique qu'avec la config dans spring-bean.xml.
 
La seule contrainte c'est qu'il faut passer à la jvm le paramètre -javaagent spring-agent.jar (ou spring-instrument.jar) suivant la version, et surement avoir les libs spring-aspectj.
Et c'est franchement pas une grosse contrainte, c'est bien expliqué.
Le loadtime weaving permet de ne pas avoir à précompiler les classes avec un compilateur aspectj.
Mais ça c'est seulement pour les gens qui veulent coller des aspects sur des classes qui ne sortent pas directement de la springfactory.
 
De toutes façons ça c'est juste une question d'interfaçage de ton code technique.
La prog aspect permet justement de greffer des aspects techniques sans modifier et salir du code métier, surtout avec des try catch.
J'ai jamais eu l'ocaz de créer des aspects, juste utilisé, mais le cas de figure que tu décris c'est typiquement là que la prog aspect à un intérêt.

Je saisis bien l'avantage de l'aspect par rapport à la problématique, mais sur ce que tu m'explique, j'ai toujours mon problème principal : l'utilisateur de cette future lib potentielle devra modifier la façon dont son projet se compile (ajout du paramètre à le JVM dans ton cas).
A mon sens, c'est au développeur de la lib de se prendre la tête avec ces choses là, pas à l'utilisateur (même si lui même est développeur). C'est ce à quoi je fais référence quand j'écris que je ne veux rien d'autre pour lui que l'ajout d'une dépendance au projet et l'annotation / fichier de conf qui va bien.
Edit : le try / catch, même si il est moche, n'a pas ce souci. L'utilisateur est devant une mécanique connue et standard au langage.

Tu n as pas voulu entendre ce que je dis.
Ta lib c est a toi de la rendre suffisament modulaire pour qu'elle soit interfaçable de diverses facon.

Avec spring par exemple tu peux tres bien gerer la gestion des connections ou des transactions a l ancienne par exemple plutot que par aspect.

Les aspects sont un bon moyen de factoriser les try catch par exemple.
Quand on se retrouve a copier coller des blocks try catch avec juste le code a l interieurdu try qui change, c est qu il y un aspect potentiel.

Dans le cas de ton truc ca me paraitrait pas idiot de le fournir avec

De notre côté, on planche sur des analyseurs de logs qui remontent des trappes d'alertes définies sur des consoles dédiées mais à vous lire, faudrait que je jette finalement un oeil sur l'AOP pour aller p-ê un peu plus loin...

 
Déjà merci de ta réponse.  
Le système de lock c'est pas tjs possible, je pense au cas ou y'a c'est la même page qui sert à la consultation que à l’édition des données.
En lockant pour l’édition je lockerais aussi la consultation...
 
Et comme l'a dit basketor63, y'a tjs le risque que une secrétaire ouvre une fiche en édition, lock et puis se casse en vacances 1 semaine sans fermer son navigateur.
 
 

Bien maintenant ils veulent que quand la secrétaire A sauve, la secrétaire B reçoit un message lui indiquant que la fiche à été modifié et demandant si elle veut actualiser la fiche (et perdre ses modif) ou garder ses modifications.
Y'a moyen de bricoler qqch avec un polling ajax un peu peur de charger inutilement les serveurs. Donc repoussé à une version HTML5 (qui permet le push serveur - client)
 
Sinon la class lock, si je la met en static dans backingbean, je vois pas trop quand je sauve comment ca me permettra de savoir si il y a eut des modifs avant dans la DB.

 
oui
 
enfin votre truc alors payave un peu tfaçon

Salut les experts,
Je suis à la recherche d'un truc style JMX mais pour une JVM 1.3
On a une appli qui prend de la mémoire tant qu'elle peut et on aimerait diagnostiquer.
Mais sous 1.3 il y a pas grand-chose (lire "rien" ) d'origine.

t'as rien trouver chez spring ?

J'ai regardé VisualVM mais ca ne marche que pour une JVM >= 1.4.2

J'allais sortir une vanne sur les fossiles mais tu as piqué ma curiosité...
-> http://java.sun.com/developer/Book [...] chap02.pdf ?

page 26

edit> Maintenant, de là à te connecter rapidos pour faire du diagnostic...

Si ça marche, t'es mon sauveur

ne parle pas trop vite... entre mettre en place un monitoring (même en 4e vitesse comme un goret) et trouver le leak, il y a (parfois) de l'eau qui passe sous les ponts

Je sais ça mais jusque là je n'avais même pas espoir de brancher du monitoring sur cette antiquité.
Du coup ca pourra pas être pire

Tiens, un retour d'expérience sur Vaadin ?

question : j'ai une property d'un bean spring
 

 
truc étant une List<String> (par exemple).
Je fais comment pour définir maList dans un fichier de properties ?  
Quelque chose genre :  
 

ou un truc du style, non ?

ouais mais là, tu initialise une liste depuis spring directement.  
Moi, je veux définir une liste dans un fichier de properties. Et injecter ces valeurs dans spring.
 
C'est pour une liste d'adresse IP : selon la plateforme, j'ai 1, 2, 5, 10 adresse IP que je veux pouvoir définir dans un fichier de propertie et utiliser ensuite dans Spring.

pour faire ça j'avais grugé.
 
tu crées un setter genre setTrucListValues(String) et donc tu balances ta String là-dedans. Et dans ton setter, tu parses la valeur pour setter véritablement ton attribut.