Remote Referenz nicht freigeben.

[Guest]

Angenommen, ich hole mir eine Referenz einer SessionBean (stateless)
auf dem Client und gebe diese während der gesamten Programmlaufzeit
nicht frei. Also kein Aufruf von "remote.remove()"

Jetzt mal abgesehen davon, dass es u.U. dazu kommt, dass eine solche
Referenz nicht mehr gültig sein kann...
Belastet es den Server, wenn man dies tut? Insbesondere, wenn da hunderte
oder gar tausende von Clients auf einen AppServer zugreifen und nichts
freigeben?

Der GarbageCollector bei RMI hält auch serverseitig einen Referenzzähler,
so dass referenzierte Objekte nicht einfach entfernt werden. Bei SSB werden
serverseitig mehrere Instanzen erzeugt (SSB Pool), die dann bei Bedarf an
die "Aufrufer" verteilt werden. Das ganze spielt sich dann nur innerhalb eines
einzelnen Methodenaufrufs ab bzw. es ist nicht garantiert, dass zwei
aufeinanderfolgende Aufrufe die gleiche Instanz eines SSB erreichen.
(spielt auch keine Rolle bei SSB)

Guter Still ist sowieso, alles, was nicht mehr benötigt wird, frei zu geben.
Dennoch würde es mich interessieren.

Was meint Ihr?

 

[Bleiglanz]

bei einer stateless ist es eh wurscht, weil die nach jedem Methodenaufruf in den Pool zurückgelegt werden kann

trotzdem sinnvoll aus Stilgründen

 

[Guest]

Die SSB's werden in den Pool geworfen, klar, da sind aber noch
paar Schichten dazwischen (mindestens RMI und die Proxies des Containers).
Hält der Server bzw. der EJB Container nicht unnötig viele Proxies
im Speicher, wenn man die Referenzen nicht freigibt?
Nach einem Methodenaufruf bleibt die Verbindung ja immer noch
erhalten, egal was serverseitig mit den SSB's geschieht.

Wenn ich mich recht erinnere, war es bei RMI immer so, dass
serverseitig erst dann die Skeletons freigegeben werden, wenn
die Verbindung zum Client unterbrochen oder clientseitig beendet
wird (Stub freigegeben).

???:L

 

[Bleiglanz]

stimmt - hängt aber wahrscheinlich davon ab, mit welchem Protokoll der Appserver arbeitet (die wenigsten nehmen das klassische RMI, viele haben da eine Eigenentwicklung im Einsatz)

wahrscheinlich ist es aus diesem Grund (Connections usw.) doch wichtig, IMMER das remove aufzurufen?!

 

[Guest]

stimmt - hängt aber wahrscheinlich davon ab, mit welchem Protokoll der Appserver arbeitet (die wenigsten nehmen das klassische RMI, viele haben da eine Eigenentwicklung im Einsatz)

wahrscheinlich ist es aus diesem Grund (Connections usw.) doch wichtig, IMMER das remove aufzurufen?!

Meinst Du mit Eigenentwicklungen unterschiedliche SocketFactories? Ich würde eher darauf tippen,
dass die meisten einen AppServer so einsetzen, wie er kommt. Meist also mit dem klassischen RMI.

Ich mache mir deswegen Gedanken darüber, da ich in einigen Projekten auf folgendes
Problem gestossen bin.
Mehrere unabhängige Komponenten greifen über eine zusätzliche Schicht (clientseitig)
auf eine SessionBean zu und die Frage, welche der Komponenten für das Beenden
der Verbindung zuständig ist, bleibt ungeklärt.
Schliessen der Verbindung mit remove() nach jedem Methodenaufruf ist nicht so sexy,
da es unnötig viele Initialisierungen der Schnittstelle erfordert.

Fällt Dir eine sichere Methode ein, mit der man feststellen kann, wie oft eine Instanz einer Klasse
referenziert wird bzw. noch interessanter, wann eine Instanz nicht mehr referenziert wird?
Leider gibt es in Java keine Destruktoren und auf die finalize() Methode ist kein Verlass.
ReferenceQueues sind in diesem Zusammenhang ein Overkill und machen die Sache nur
unnötig kompliziert.

 

[Bleiglanz]

scheinbar doch überflüssig:

http://www.theserverside.com/discussions/thread.tss?thread_id=7051

 

[Guest]

Danke. Ohh, im TSS Forum habe ich nicht gesucht. :autsch:
Insbesondere die vorletzte Antwort deutet darauf hin, dass es sogar
von SUN bestätigt wurde.

OK, hat sich erledigt. :wink: