Version imprimable
Bonjour,
Je souhaiterai savoir comment faire pour que 2 programmes utilisant la même machine virtuelle accèdent a 1 objet commun. Un objet partagé en gros. Le principe: Le prog 1 se lance et crée la liste si elle n'existe pas, puis le programme 2 se lance et ne crée pas l'objet puisqu'il existe deja mais il peut y accéder. Si les 2 programmes sont arrêtés on libère l'objet.
De quel côté je devrai m'orienter?
Si vous avez une idée c'est cool!
Merci
salut, je suis encore débutant mais je pense si tes deux programme sont dans le meme package tu devrai pouvoir faire hérite ta classe du programme 2 de la classe du programme 1 ca permettrai a ta classe 2 d'avoir acces a tout les objets déclarer dans ta classe 1....
heu je suis pas sur d'avoir été clair et si ca va marcher mais c'est par la que je chercherai si j'étais toi...
a+
Si j'ai bien compris ton problème, tu veux que quand un programme est lancé deux fois de suite il ne crée pas deux fois le même objet.
Tu pourrais sérialiser ton objet "partagé" dans un fichier en oubliant pas de régler les problèmes de concurrence d'accès.
tu devrais regarder du coté de la serialisation ..
un petit lien pour commencer
Erf... J'avais pas compris ca moi :?Citation:
Envoyé par verbose
explique toi clairement MC wacko tu as deux programmes differends ou un seul que tu lance deux fois ?
a+
Ca revient au même problème. Ce sont deux exécutions différentes, deux processus différents. On peut soit serialiser soit s'appuyer sur un 3 ème acteur qui est un service permanent (RMI).Citation:
Envoyé par nayah
On peut pas faire hériter l'un par rapport a l'autre alors ? Le deuxieme bénificierai de l'objet creer par le premier non ?Citation:
Envoyé par Duc Lebowski
Je ne vois pas ce que l'héritage vient faire là dedans ! Tu n'as qu'à faire le test pour t'en convaincre ;)
Soient :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
je comprends trés bien ce que tu veux me montrer mais juste une derniere question... dans ton exemple , un objet creer par la classe animal sera bien accessible par la classe chien non ?
donc si classe2 extends classe1 , un objet creer dans classe1 sera accessible par classe2... ou alors j'ai vraiment rien compris a l'heritage (ce qui est hautement probable :aie: )
Tu confonds "héritage" et "static".
La valeur d'un attribut "static" d'une classe sera effectivement partagée par l'ensemble des instances de cette classe, mais dans tous les cas cela reste valable que au sein d'un même processus Java !
L'héritage est une notion purement conceptuelle qui permet de regrouper des attributs/comportements communs à différents objets au sein d'une classe mère. Cela ne veut pas dire qu'ils partagent leurs informations (valeurs), cela veut simplement dire qu'ils "fonctionnent de la même manière...". L'héritage est principalement utile pour le polymorphisme. Certains diront aussi pour capitaliser du code mais là il faudrait en discuter plus longuement car ce n'est pas toujours bon de le considérer ainsi.
Quant à savoir si l'attribut sera accessible ou pas depuis l'extérieur, c'est une question purement de visibilité (private, protected, public). Effectivement une classe qui hérite d'une classe mère pourra en utiliser les méthodes protected alors que si elle ne fait pas partie du même package elle n'a pas le droit de le faire autrement. Au passage, s'appuyer sur l'héritage pour essayer de récupérer l'accès à des méthodes protected ai généralement d'un très mauvais goût (cf principe de Substitution de Liskov).
Bonjour, si les 2 programmes sont dans la même jvm, c'est qu'ils ont été lancés par un "launcher": Tomcat, ou autre serveur d'appli. Il faudrait préciser dans quel contexte tu es car ça peut poser problème.Citation:
Envoyé par MC wacko
sinon, le moyen est de partager un instance unique communes aux 2 progs pour partager leurs objets:avec un singleton (classe instanciée une seule fois, dont la méthode getInstance renvoie toujours la même instance, via un attribut de classe.)
La sérialisation est certainement la méthode la plus simple, sinon il y d'autres méthodes : ipc, sockets, rmi etc.
ok j'ai compris ton explication duc merci je vois que j'ai encore beaucoup a apprendre :mrgreen:
Salut :yaisse2:
Merci a tous pour vos réponses mais je pense pas avoir été assez précis dans mon premier post.
Le principe c'est d'avoir une pile très basique pour gérer l'envoi et la réception de messages entre processus (de façon asynchrone). Un peu comme JMS je crois mais sans middleware.
En théorie les programmes utilisant la pile sont différents mais en pratique pour des raisons de simplicité ils seront identiques. Pas possible donc d'utiliser de static
Voila comment je compte procéder:
Le premier prog lancé crée la pile, puis il peut envoyer des messages qui y seront stockés. Ensuite d'autres programmes sont lancés et peuvent faire de même. Puis tous les soirs par exemple ou toutes les heures chaque processus vérifie l'état de la pile et récupère ses messages. J'ai donc besoin d'avoir un objet "commun" à tous les processus afin qu'ils puissent y accéder.
L'idéal serait que tout se fasse en RAM afin d'éviter les accès disques trop nombreux.
Je ne compte pas gérer l'accès concurrent pour le moment. Un seul thread quoi parce qu'il faut commencer doucement.
RMI est trop compliqué à mettre en oeuvre pour le moment mais je pense m'y coller histoire de tester.
La sérialisation me paraît être la meilleure solution mais cela risque de poser des problèmes de performances. En gros dans mon cas cela voudrait dire que pour chaque message ajouté à la pile il faudrait un accès disque. Comme dit plus haut je pensai sérialiser cet objet si tous les processus sont stoppés afin de le réinitialiser au prochain lancement d'un processus.
Perso, si j'étais à ta place, j'utiliserais les sockets, la sérialisation se ferait au travers de ces dernières.