Ein Lifecycle Objekt ist im Grunde ein Container für beliebige Objekte und Methoden/Actions die Serverseitig verwaltet werden. Mit Lifecycle Objekten wird die Business Logik für den Client zur Verfügung gestellt.
Jedes Lifecycle Objekt hat einen vordefinierten Lebenszyklus. Wenn dieser endet wird einerseits das Lifecycle Objekt verworfen und andererseits alle damit verwalteten Objekte. Der Speicherverbrauch des Applikationsservers wird dadurch stark optimiert.
Nachfolgende Grafik gibt einen Überblick über die Lebenszyklen innerhalb einer Applikation:
Das Beispiel zeigt 2 Unterschiedliche Applikationen (Applikation-A und Applikation-B) die nacheinander auf die Business Logik des Servers zugreifen.
Jede Applikation benötigt eine MasterConnection um überhaupt auf den Server zugreifen zu können. Mit der MasterConnection kann die Business Logik aufgerufen werden, mit sogenannten calls.
Beim jeweils ersten call einer Connection wird das zugehörige Lifecycle Objekt instanziert, damit der call auf das richtige Business Objekt angewandt werden kann. Das Lifecycle Objekt bleibt bestehen bis die zugehörige Connection geschlossen wird. Zu diesem Zeitpunkt werden auch alle verwalteten Objekte verworfen und der verwendete Speicher wird wieder freigegeben.
Für SubConnections gilt das gleiche Verhalten wie für MasterConnections.
Die Ausnahme ist das Applikations Business Objekt. Dabei handelt es sich um ein Lifecycle Objekt, das beim ersten call einer Applikation instanziert wird und bestehen bleibt bis der Applikationsserver gestoppt wird. Pro Applikation existiert genau 1 Applikations Lifecycle Objekt, unabhängig davon wieviele Benutzer an der Applikation angemeldet sind.
Hinweis
Ein Lifecycle Objekt sollte Stateless verwendet werden, da der Server die Lifecycle Objekte bei Bedarf neu instanzieren kann. Das bedeutet daß alle gespeicherten Informationen/Objekte verworfen werden!
Dieses Verhalten muss bei benutzerdefinierten Objekten berücksichtigt werden, bedeutet aber nicht, daß Stateful Objekte nicht unterstützt werden.