StorageService

Der StorageService speichert Daten für den Integration Server, entweder kurzzeitig im Arbeitsspeicher oder langfristig. Sie können diese Daten über eine einfache ID wiederfinden.

Um Daten persistent zu speichern, benötigen Sie einen PersistentManager (siehe weiter unten).

XML-Konfiguration

Setzen der Standardwartezeit

Das folgende XML-Fragment legt die Wartezeit zwischen zwei Gültigkeitsprüfungen der gespeicherten Werte fest.

<Set name="waitTime">5000</Set>

Die Wartezeit wird in Millisekunden angegeben.

Setzen eines PersistentManagers

Das folgende XML-Fragment setzt und aktiviert den DefaultPersistentManager für den StorageService. Sie übergeben dieses Argument bei der Initialisierung des DefaultPersistentManagers. Das Argument gibt das Verzeichnis an, in dem der StorageService die Objekte speichert.

<Call name="setPersistentManager">
	<Arg>
		<New class="com.ebd.hub.services.storage.DefaultPersistentManager">
			<Arg>./logs/storage</Arg>
		</New>
	</Arg>
</Call>

Das folgende XML-Fragment setzt und aktiviert den JDOPersistentManager für den StorageService. Sie übergeben dieses Argument bei der Initialisierung des JDOPersistentManagers. Das Argument gibt den zu verwendenden Datenbank-Alias an.

<Call name="setPersistentManager">
	<Arg>
		<New class="com.ebd.hub.services.storage.JDOPersistentManager">
			<Arg>hub</Arg>
			<Set name="optimizeTables">true</Set>
		</New>
	</Arg>
</Call>

Lobster empfiehlt in einem Load-Balancing-Umfeld die Datenbank Redis. Das folgende XML-Fragment setzt und aktiviert den RedisPersistentManager für den StorageService.

<Call name="setPersistentManager">
	<Arg>
		<New class="com.ebd.hub.services.storage.RedisPersistentManager">
			<Arg>redis://localhost:6379</Arg>
			<Arg>my password</Arg>
		</New>
	</Arg>
</Call>

Wenn Sie bestehende Einträge vom JDOPersistentManager migrieren möchten, geben Sie den Datenbank-Alias des JDO-Managers an.

<Call name="setPersistentManager">
	<Arg>
		<New class="com.ebd.hub.services.storage.RedisPersistentManager">
			<Arg>redis://localhost:6379</Arg>
			<Arg>my password</Arg>
			<Set name="jDOAlias">hub</Set>
			<!-- only needed to migrate from JDOPersistentManager -->
		</New>
	</Arg>
</Call>

Wenn Sie einen Redis-Cluster ansprechen möchten (hier aus den drei Maschinen node1, node2 und node3), verwenden Sie das folgende XML-Fragment.

<Call name="setPersistentManager">
	<Arg>
		<New class="com.ebd.hub.services.storage.RedisPersistentManager">
			<Arg>
				<New class="java.util.HashSet">
					<Call name="add">
						<Arg>
							<New class="redis.clients.jedis.HostAndPort">
								<Arg>node1</Arg>
								<Arg type="int">6379</Arg>
							</New>
						</Arg>
					</Call>
					<Call name="add">
						<Arg>
							<New class="redis.clients.jedis.HostAndPort">
								<Arg>node2</Arg>
								<Arg type="int">6379</Arg>
							</New>
						</Arg>
					</Call>
					<Call name="add">
						<Arg>
							<New class="redis.clients.jedis.HostAndPort">
								<Arg>node3</Arg>
								<Arg type="int">6379</Arg>
							</New>
						</Arg>
					</Call>
				</New>
			</Arg>
			<Arg>my password</Arg>
		</New>
	</Arg>
</Call>

Allgemeine Einstellungen

(1) Die Wartezeit zwischen zwei Gültigkeitsprüfungen der gespeicherten Werte.

(2) Der verwendete PersistentManager und das Verzeichnis, in dem er die Objekte speichert.

Aktuell verwaltete Objekte

(1) Die Liste der aktuell verwalteten Objekte. Für jedes Objekt zeigt die Liste den eindeutigen Schlüssel, den Persistenzstatus, die Zeit bis zur Entfernung bei fehlendem Zugriff und den Wert, falls dieser darstellbar ist. Über das Kontextmenü löschen Sie ein Objekt aus dem Speicher.

Loglevel-Abhängigkeiten

Änderungen des Loglevels beim LogService haben keinen Einfluss auf das Logverhalten des StorageServices.

Wenn Sie den Service in den Verbose-Modus setzen, protokolliert er die Schlüssel aller hinzugefügten und entfernten Einträge.

Verhalten bei Verlust der Datenbankverbindung

Ab Version 26.3.0 gilt: Verliert der StorageService die Verbindung zur Datenbank, prüft die Lobster Data Platform wiederholt, ob die Datenbank wieder erreichbar ist. Bleibt die Verbindung dauerhaft unterbrochen, beendet sich die Lobster Data Platform mit dem Exit-Code 136.

Der Lobster Application Wrapper erkennt diesen Exit-Code und startet die Lobster Data Platform automatisch neu. Ein Update wird dabei nicht ausgeführt. Der Neustart durchläuft ausschließlich die reguläre Startsequenz.

Die Lobster Data Platform beendet sich nicht beim ersten fehlgeschlagenen Verbindungsversuch. Ein interner Mechanismus löst den Shutdown erst aus, nachdem mehrere aufeinanderfolgende Verbindungsversuche fehlgeschlagen sind. Derselbe Mechanismus greift, wenn die Datenbank beim Start der LDP nicht erreichbar ist.

 HINWEIS
Der automatische Neustart setzt voraus, dass die Lobster Data Platform unter dem Application Wrapper läuft. Starten Sie die Lobster Data Platform direkt ohne Wrapper, findet kein automatischer Neustart statt.

Hintergrund: Der StorageService verwaltet zentrale Daten wie eindeutige Job-Nummern und Auto-Nummern, die für interne und kundenspezifische Prozesse benötigt werden. Können diese Daten aufgrund fehlender Datenbankverbindung nicht persistiert werden, beendet sich die LDP, um Informationsverlust zu vermeiden. Der Neustart über den Wrapper stellt einen definierten Wiederanlauf sicher.

In früheren Versionen vor 26.3.0 verblieb die Lobster Data Platform bei dauerhaftem Verlust der Datenbankverbindung in einer Wiederverbindungsschleife. Ein gezielter Shutdown mit anschließendem Neustart durch den Wrapper fand nicht statt.