# Remote Referenz nicht freigeben.



## Guest (1. Sep 2005)

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 (1. Sep 2005)

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 (1. Sep 2005)

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 (2. Sep 2005)

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 (2. Sep 2005)

Bleiglanz hat gesagt.:
			
		

> 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 (2. Sep 2005)

scheinbar doch überflüssig:

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


----------



## Guest (2. Sep 2005)

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:


----------

