Codedesign für modulare Anwendung

[Codehunter]

Zitat von mjustin:

Müssen alle Datenbankverbindungen denn ständig geöffnet sein?

Soweit ich weiß öffnet UniDAC die eigentliche Verbindung nur dann, wenn ein DataSet auf Active = TRUE gesetzt wird. Gewohnheitsmäßig öffne und schließe ich die Verbindung vor bzw. nach einer Datenbank-Transaktion. Das geht aber nur, solange man nicht mit DB-Aware-Komponenten arbeitet. Davon unabhängig kann man bei UniDAC verschiedene Server-Parameter angeben, darunter auch den Connection Timeout. Per Default ist der 15 Sekunden, danach wird die Verbindung abgebaut.

Trotzdem kann der User theoretisch die Anwendung dazu bringen, mit vielen gleichzeitig geöffneten Modulen 20 oder 30 offene Datenbank-Sessions zu erzeugen. Darum war mein Gedanke, ich verwende nur eine zentrale UniConnection-Komponente und lasse sämtliche Module einer Anwendungsinstanz darüber laufen. Dann würde das ConnectionTimeout-Management auch viel besser funktionieren.

[mjustin]

Zitat von Codehunter:

Zitat von mjustin:

Müssen alle Datenbankverbindungen denn ständig geöffnet sein?

Soweit ich weiß öffnet UniDAC die eigentliche Verbindung nur dann, wenn ein DataSet auf Active = TRUE gesetzt wird. Gewohnheitsmäßig öffne und schließe ich die Verbindung vor bzw. nach einer Datenbank-Transaktion. Das geht aber nur, solange man nicht mit DB-Aware-Komponenten arbeitet.

Das gilt nicht, wenn man mit ClientDataSet arbeitet, denn ein an ein ClientDataSet gebundene Datenbankkomponenten zeigen auch nach dem Schliessen des Datasets weiter alle Daten an und erlauben auch Eingaben. Für das Speichern wird dann wieder eine Verbindung aufgebaut.

Damit kann die Anwendung praktisch 99% der Zeit Offline, ohne Connection (und benutzte Lizenz) arbeiten.

[Furtbichler]

Ich wollte nur kurz etwas zur Eingangsfrage einwerfen:

Zitat von Codehunter:

Darum war mein Gedanke, ich verwende nur eine zentrale UniConnection-Komponente und lasse sämtliche Module einer Anwendungsinstanz darüber laufen. Dann würde das ConnectionTimeout-Management auch viel besser funktionieren.

Ich finde nicht, das das eine gute Idee ist, denn dadurch würden Zugriffe doch unnötigerweise serialisiert. Mir scheint, das UniDAC hier ein Connection-Pooling eingebaut hat, was sehr praktisch ist. Ich sehe nämlich überhaupt keinen Nachteil, 20-30 Verbindungen gleichzeitig offen zu halten: Den Server juckt das doch gar nicht. Durch das Pooling will man doch gerade das umständliche Weiterreichen einer TConnection vermeiden.

Das Pooling unterstützt ja direkt das Plugin-Konzept. Jedes Plugin holt sich eine eigene Connection und muss sich nicht darum scheren, ob da gerade eine Transaktion läuft, oder nicht.

Das entbindet dich aber nicht davon, Connection- oder Transaktionskomponenten weiterzureichen, gerade *wegen* der Transaktionsproblematik.

[Codehunter]

Soweit ich UniDAC verstanden habe, betreibt dieses ein Transaktionspooling und kein Verbindungspooling. Das Pooling findet in der TUniConnection statt und gerade deswegen hielt ich es für eine gute Idee, die Verbindung zwischen Hostanwendung und Plugin zu teilen.

Im Gegensatz zu Webservern a la Apache oder IIS scheinen Datenbankserver wie MySQL und MariaDB gar nicht so begeistert zu sein über viele konkurrierende Verbindungen. Per Default scheinen die auf weniger als 100 gleichzeitige Verbindungen eingestellt zu sein.