Multithreading und Datenbanken

[QuickAndDirty]

Zitat von mjustin:

Zitat von QuickAndDirty:

1 = asyncron (quasi eigener Thread Fire and forget)
2 = syncron (von denen kann nur eine gleichzeitig laufen, neben anderen asnycronen...)
3 = Mainthread(die Function wartet auf das ende aller threads und blockiert dann das ausführen weiterer, sie wird im Hauptthread ausgeführt...wegen blöder VCL abhängigkeit)

Zitat von mjustin:

1 = unproblematisch, kann parallel mehrere Clientanfragen entgegennehmen und auch multithreaded laufen?

Es ist so: Diese Aufgabe kann parallel oder zu irgendeiner aufgabe laufen, darf ruhig unterbrochen werden &c.
meist jedoch sind es so kleine aufgaben (abschicken eines Query ...) das da kein synchronisationsbedarf existiert,

Zitat von mjustin:

2 = alle Clientanfragen müssen serialisiert werden (Queue) da es sonst "Matsche" gibt?

Aufgaben vom Typ 2 kommen in eine queue mit den aufgaben von typ 3 und werden immer nur eine nach der anderen bearbeitet.

Zitat von mjustin:

3 = in einem Atozed Intraweb Server werden VCL Teile verwendet?

Nein wir haben 2 Programme einen Applikation server mit der Queue und den Funktionen und eben der Geschäftlogik &c. Der Atozed webserver rendert das ganze nur.

Zitat von mjustin:

Für den letzten Punkt wäre eine Alterative, seine Verarbeitung aus der Intraweb Anwendung auszulagern in externe Prozesse, damit das blockieren der anderen Threads nicht mehr nötig ist. Könnte man einen eigenen Prozess je Clientanfrage starten, der nach dem Beenden seine Ergebnis-Daten irgendwie an Intraweb zurückliefert, oder einen Pool ständig laufender VCL-Anwendungen verwenden, die sich gegenseitig nicht mehr behindern können? Damit wäre der Server bzw seine Kerne besser ausgelastet.

Vermutlich ist die beste lösung daran zu arbeiten das der Applicationserver MultiInstanzfähig wird.

Zitat von mjustin:

Ist in Punkt zwei gemeint, dass es global genutzte Resourcen gibt die verhindern, mehrere Clientanfragen parallel auszuführen? (zum Beispiel eine Datenbanktabelle die für die gesamte Dauer der Requestverarbetung exklusiv einem Client gehört)?

Nun, zu BDE zeiten gab es eine DB mit Localen Tabellen wenn da mehr als ein vorgang drauf gearbeitet hat gabs keine vernünftigen Ergebnisse...die sind allerdings mittlerweile abgeschafft bzw. als Durchnummerierte Temp_Tabellen in der normalen DB untergebracht.
Der andere Ultimative Grund ist der das wir sowas wie ein "Security Objekt" für den gerade angemeldeten benutzer haben (*facepalm*) alle möglichen alten Funktionen beziehen informationen von "DEM" im Applicationserver angemeldeten Benutzer.

Vermutlich macht es durchaus mittelfristig Sinn den Angemeldeten benutzer genauso wie im Webserver an den Thread zu kleben....leider ist der zur zeit noch Global.(*Aua*)

Das einfachste dürfte es wohl sein dem FB mehrere Prozessoren zu geben und mehrere instanzen des Applicationservers laufen zu lassen. Da müsste man dann noch drann arbeiten

wie geben ich dem FB mehrere Prozessoren?