Reprise du message précédent :

 
nraynaud-> merci

on s'en fout, il charge la mule comme un porc pour tenter de reproduire un race, à tous les coups.
 
 
-- > tu as peut-être aussi l'option de charger la machine par un autre programme que ta JVM d'ailleur, un truc à côté.

BigInteger powa

IllegalMonitorStateException

bon, y'a un truc que je dois pas avoir pigé. dans les thread, j'ai le code ci-dessus, et dans mon thread principal j'ai

mais ça bloque

(pssst, je conseil gratuit de nraynaud : les nombres sont TOUJOURS des objets immuables)
 
DONC TU VA ME REMPLACER TA BOUSE PAR UN HOLDER DE VALUE.

putain, c'est le premier mot de la javadoc en plus.

(euh oui je viens de le faire mais ça bloque quand meme )

refais-voir le code modifié ?

ça bloque à quelle ligne exactement ? avec quelle valeur de value ?

ça bloque sur le wait à priori
 
doit y'avoir un truc gros comme un camion qui m'échappe...

en tout cas, ça me parraît pas mal, mais je suis jamais sûr de mon coup en concurrence, en jouant avec volatile, c'est mieux ? (pourtant le bloc synchronized devrait suffire)

je parlais du thread qui était sensé débloquer les choses.

bon c'est mon value=value-- qui est pas bon évidemment

pkoi tu te sers pas d'un ThreadGroup ? ca compte les threads qui tournent pour toi ...

ha j'aurais pu - connaissais pas. trop tard. comme dit, ct un gros test bourrin pour tenter de reproduire une merdouille.  
pas reproduit, d'ailleurs

ça leur aurait arraché la gueule d'implementer le support pour NVL dans leur plugin ejb de merde à jboss putain?
 
(a part ça y'a le support pour des fonctions completement inutiles du genre abs ou sqrt )

 
Il doit pas y avoir un counter.wait() "dans" ton thread principal et un notify() dans la méthode desc() de Counter ???

ben c'est ce que j'ai à peu de choses pres: c'est les thread-non principaux qui font if counter.isZero then counter.notify
 
 
ET AU FAIT CA MARCHE MAINTENANT HEIN PAS BESOIN DE QUOTER CE TRUC PENDANT LES 20 PAGES QUI VIENNENT

toujours un as avec les threads à ce que je vois

 
bin ne l'écris pas avec de l'EJB-QL

j'ai *jamais* fait de multithreading
 

ouais ok

surprenant pour quelqu'un qui fait des EJB et de la prog web à longueur de journée  

ben justement, les servers l'ont tjs fait pour moi
(quand je dis jamais j'exagère, mais en gros, les rares fois ou j'ai démarré des threads, c'etait pour reproduire des bugs dus au multithreading, soit.. bah euh l'autre example dont je me rappelle, j'avais demandé à darklord à l'epoque.. d'ailleurs chuis pas convaincu que j'avais bien fait ça)

tiens bah justement :  
c fiable l'héritage d'EJB ou vaut mieux éviter ?

il fut un temps où c'était fortement déconseillé parce que chaque conteneur gérait ca à sa façon ... je sais pas si ca a été normalisé par la suite ... il me semble pas, mais je suis vraiment pas sûr

c bien ce que je craignais...on va pas jouer avec le feu alors ...

avec jboss ça marche, du moins pour ce que l'api moisie laisse faire; et je vois pas pq ça marcherait pas pour d'autres?

c'est surtout pour les entity que le problème se pose : y a plusieurs façon de représenter un héritage en BDD ...

ben ce serait pour des entity CMP, sous WSAD 5.1.2 ...(lequel doit faire tourner les projets sous Websphere business integration 5 je crois)
 
des potes ont testé, et c ok pour les create, mais les remove ont l'air de foirer...je voulais savoir si ils s'y étaient pris comme des branques, ou si ct vraiment une limite du modèle...

ha ok oui moi j'ai jamais fait ça qu'avec des SLSB et des MDB.
 
(hibernate rulez pour le mapping de l'heritage en db, tu fais tout ce que dont tu peux rever - d'ailleurs un 'find' sur un Type donné tu renvoies aussi des instances de SousType, meme si elles sont stockées dans une table séparée

ouais mais on est quand assez souvent confronté à faire gaffe à l'accès à des ressources partagées ... enfin moi c'est pas rare que ca m'arrive  

dans ce cas, soit tu potasses les spec de WS pour être sûr que ca fait tout ce que tu veux comme tu le veux, soit tu évites l'héritage ...

oui et quel est le rapport? j'ai dit (voulu dire) que j'avais très peu fait joujou avec des threads "manuellement" - évidemment que j'ai plus que souvent fait face à des questions/problemes de multithreading, cfr mon post ou je t'ai dit ds quels cas j'avais fait des threads à la main...

ouais, t'as raison, c'est pas pareil ... c'est vrai que c'est dans d'autres cas que je créé mes threads ... mais bon, c'est quand même sureprenant que t'ai jamais eu l'occasion de t'y confronter.

jamais avec des guillemets. jamais en profondeur ni très sérieusement.
question de projets

 
 
tu veux dire que tu fais des BMP et que tu gères la persistence toi meme avec Hibernate ?

euh non

 
Toujours pareil, les mauvaises nouvelles sont vites relayées, pas les bonnes.
JDO 2.0 est adopté.  
 
Il existe désormais un standard pour la persistance Java. Ce standard est partagé par plusieurs solutions. Les applications développées avec JDO peuvent être J2EE ou non. JDO supporte l'ensemble des concepts objets. Ceci est pratique pour faire des applications modernes, riches et complexes, sauf bien sur si on a pour seule ambition de refaire en Java des applications qui marchent depuis longtemps.
Les applications JDO 2.0 sont neutres par rapport à la base de données, par rapport au serveur d'application et même par rapport à l'implémentation JDO choisie.
De plus la concurrence autour du même standard garantie le meilleur outillage pour le développeur, les meilleures performance et le moindre risque pour la perennité.

 
Oublie le modèle objet quand tu utilises les CMP. Ce sont des composants plus que des objets. Cela n'a absolument rien à voir avec les possibilités fines proposées par Hibernate.