J'aurais besoin de renseignements sur RMI et surtout d'une confirmation sur
la capacité de RMI à gérer nativement les accès concurrents.
Soit la situation suivante :
2 objets font simultanéement la même requête sur un serveur RMI.
Que fait le serveur ?
Sait-il répondre aux 2 (les 2 clients aurant donc une réponse et donc RMI
est multithread) ou
l'un des 2 (ou les 2) se verra recevoir une remoteException ?
Si quelqu'un pouvait m'apporter une réponse, celai m'aiderait énormément.
Merci.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
tomcat
Christophe wrote:
Salut à tous,
J'aurais besoin de renseignements sur RMI et surtout d'une confirmation sur la capacité de RMI à gérer nativement les accès concurrents. Soit la situation suivante : 2 objets font simultanéement la même requête sur un serveur RMI. Que fait le serveur ? Sait-il répondre aux 2 (les 2 clients aurant donc une réponse et donc RMI est multithread) ou l'un des 2 (ou les 2) se verra recevoir une remoteException ?
Si quelqu'un pouvait m'apporter une réponse, celai m'aiderait énormément. Merci.
Chris
A priori, RMI gére son pool de connexion lui même par le bias de threads
Christophe wrote:
Salut à tous,
J'aurais besoin de renseignements sur RMI et surtout d'une confirmation sur
la capacité de RMI à gérer nativement les accès concurrents.
Soit la situation suivante :
2 objets font simultanéement la même requête sur un serveur RMI.
Que fait le serveur ?
Sait-il répondre aux 2 (les 2 clients aurant donc une réponse et donc RMI
est multithread) ou
l'un des 2 (ou les 2) se verra recevoir une remoteException ?
Si quelqu'un pouvait m'apporter une réponse, celai m'aiderait énormément.
Merci.
Chris
A priori, RMI gére son pool de connexion lui même par le bias de threads
J'aurais besoin de renseignements sur RMI et surtout d'une confirmation sur la capacité de RMI à gérer nativement les accès concurrents. Soit la situation suivante : 2 objets font simultanéement la même requête sur un serveur RMI. Que fait le serveur ? Sait-il répondre aux 2 (les 2 clients aurant donc une réponse et donc RMI est multithread) ou l'un des 2 (ou les 2) se verra recevoir une remoteException ?
Si quelqu'un pouvait m'apporter une réponse, celai m'aiderait énormément. Merci.
Chris
A priori, RMI gére son pool de connexion lui même par le bias de threads
Sebastien
tomcat wrote:
Christophe wrote:
Salut à tous,
J'aurais besoin de renseignements sur RMI et surtout d'une confirmation sur la capacité de RMI à gérer nativement les accès concurrents. Soit la situation suivante : 2 objets font simultanéement la même requête sur un serveur RMI. Que fait le serveur ? Sait-il répondre aux 2 (les 2 clients aurant donc une réponse et donc RMI est multithread) ou l'un des 2 (ou les 2) se verra recevoir une remoteException ?
Si quelqu'un pouvait m'apporter une réponse, celai m'aiderait énormément. Merci.
Chris
A priori, RMI gére son pool de connexion lui même par le bias de threads
RMI te permet d'accéder à un objet distant de façon 'quasi' transparente. Quand tu possèdes une instance remote (RemoteStub) d'un objet, tu peux l'utiliser comme si tu avais réellement cet objet, sans te soucier de savoir si qq'un d'autre y a aussi accès. Si tu veux régler le problème des accès concurrents à ton objet, mets des 'synchronized'!
Sébastien
tomcat wrote:
Christophe wrote:
Salut à tous,
J'aurais besoin de renseignements sur RMI et surtout d'une
confirmation sur
la capacité de RMI à gérer nativement les accès concurrents.
Soit la situation suivante :
2 objets font simultanéement la même requête sur un serveur RMI.
Que fait le serveur ?
Sait-il répondre aux 2 (les 2 clients aurant donc une réponse et donc RMI
est multithread) ou
l'un des 2 (ou les 2) se verra recevoir une remoteException ?
Si quelqu'un pouvait m'apporter une réponse, celai m'aiderait énormément.
Merci.
Chris
A priori, RMI gére son pool de connexion lui même par le bias de threads
RMI te permet d'accéder à un objet distant de façon 'quasi' transparente.
Quand tu possèdes une instance remote (RemoteStub) d'un objet, tu peux l'utiliser comme si tu avais
réellement cet objet, sans te soucier de savoir si qq'un d'autre y a aussi accès.
Si tu veux régler le problème des accès concurrents à ton objet, mets des 'synchronized'!
J'aurais besoin de renseignements sur RMI et surtout d'une confirmation sur la capacité de RMI à gérer nativement les accès concurrents. Soit la situation suivante : 2 objets font simultanéement la même requête sur un serveur RMI. Que fait le serveur ? Sait-il répondre aux 2 (les 2 clients aurant donc une réponse et donc RMI est multithread) ou l'un des 2 (ou les 2) se verra recevoir une remoteException ?
Si quelqu'un pouvait m'apporter une réponse, celai m'aiderait énormément. Merci.
Chris
A priori, RMI gére son pool de connexion lui même par le bias de threads
RMI te permet d'accéder à un objet distant de façon 'quasi' transparente. Quand tu possèdes une instance remote (RemoteStub) d'un objet, tu peux l'utiliser comme si tu avais réellement cet objet, sans te soucier de savoir si qq'un d'autre y a aussi accès. Si tu veux régler le problème des accès concurrents à ton objet, mets des 'synchronized'!
