Search the FirstSpirit Knowledge Base
Liebe FirstSpirit Community,
wir arbeiten zur Zeit an einem System, dass über die Access API (mit Content2) Anfragen an FirstSpirit stellt.
Dabei wird aktuell eine Verbindung über das Instanziieren der FS eigenen Connection Klasse
Aufgebaut, eine Anfrage gesendet und am Ende die Verbindung wieder geschlossen. Allerdings
Ergeben sich dadurch Probleme mit nebenläufigen Anfragen, da hier der Verbindungsaufbau
Durch den Server blockiert wird. Die Ursache hierfür scheint zu sein, dass eine einzelne Connection
Keine nebenläufigen Anfragen bearbeiten kann. Es kann leider auch nicht für jede Anfrage eine
Neue Connection erzeugt werden, da sonst sehr schnell die maximale Anzahl erlaubter Sessions
Erreicht ist und unser FS User überhaupt keinen Zugriff mehr hat.
Gibt es eine Möglichkeit, eine Connection aufzubauen, die mit nebenläufigen Anfragen umgehen kann?
Oder existieren alternativ Funktionen, die im Rahmen der Anzahl erlaubter Sessions vordefinierte Connections
Auf Anfragen verteilen?
Unsere FS Version: 5.2
Vielen Dank.
Mit freundlichen Grüßen
Ronny Schottstädt
Hallo Ronny,
soweit ich weiß sind parallele Anfragen über eine FS-Connection nicht möglich.
Seit FirstSpirit 5.2.1604 gibt es die Klasse ConnectionExtractor, über das sich in einer WebApp die Connection im ServletRequest auslesen und nutzen lässt.
Aber ich glaube das bringt euch nicht viel weiter.
Spricht etwas dagegen in eurem System einen festen Pool an FS-Connections zu halten und wiederzuverwenden? Oder auf irgendeine andere Art die Zahl paralleler Anfragen zu begrenzen?
Viele Grüße
Tim
Hallo Ronny,
soweit ich weiß sind parallele Anfragen über eine FS-Connection nicht möglich.
Seit FirstSpirit 5.2.1604 gibt es die Klasse ConnectionExtractor, über das sich in einer WebApp die Connection im ServletRequest auslesen und nutzen lässt.
Aber ich glaube das bringt euch nicht viel weiter.
Spricht etwas dagegen in eurem System einen festen Pool an FS-Connections zu halten und wiederzuverwenden? Oder auf irgendeine andere Art die Zahl paralleler Anfragen zu begrenzen?
Viele Grüße
Tim
Hallo Ronny,
kannst du uns vielleicht noch den Anwendungsfall beschreiben der sich hinter der technischen Fragestellung verbirgt? Was macht das "System"? Wo wird die Connection aufgerufen? Innerhalb einer Vorschauseite?, aus einem externen Services heraus?
Viele Grüße,
Daniel
Hallo zusammen,
vielen Dank für Eure Antworten! Nochmal zum Projekt: Wir entwickeln zur Zeit eine mobile Applikation, welche über ein Back-End Daten vom FirstSpirit-Server abruft und visualisiert. Bei jedem Aufruf, baut das Back-End eine Verbindung zum FirstSpirit-Server auf und übergibt die angeforderten Daten an das Front-End.
Das Problem wurde jetzt so gelöst, dass die Anfragen an den FirstSpirit-Server als Callable in einem ExecutorService gestellt werden. Den ExecutorService haben wir in einem Singleton initialisiert und die Menge der Threads begrenzt. Unter Last wird diese Lösung früher oder später zu hohen Ladezeiten führen, weshalb wir zeitnah über ein Caching nachdenken werden. Im Folgenden findet Ihr den Code, welchen wir verwenden.
ExecutorService-Singleton:
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ConnectionExecutorService {
private static ConnectionExecutorService instance;
private final int NUMTHREAD = 5;
ExecutorService executorService;
public static ConnectionExecutorService getInstance() {
if (instance == null){
instance = new ConnectionExecutorService();
}
return instance;
}
private ConnectionExecutorService() {
executorService = Executors.newFixedThreadPool(NUMTHREAD);
}
public ExecutorService getExecutorService() {
return executorService;
}
}
Verwendung eines Callable:
import java.util.concurrent.Callable;
...
Callable<AnyTypeYouWant > callable = new Callable<AnyTypeYouWant >() {
public AnyTypeYouWant call() throws Exception {
// Enable Connection to FS-Server
// Execute Query
// Disconnect
return result;
}
}
(AnyTypeYouWant) ConnectionExecutorService.getInstance().getExecutorService().submit(callable).get();
Danke nochmal und viele Grüße,
Ronny