Zugriff auf eine *.ini-Datei über mehrere Rechner im Netzwerk

[Jean]

Hallo an alle Delphispezialistinnen und -spezialisten,

ich bin noch so ziemich bei den Anfängen der Programmierung mit Delphi. Daher folgende Frage:

Kann es zu Problemen führen, wenn eine Anwendung, die auf ca. 200 Rechnern in einem Netzwerk läuft, auf die gleiche ini-Datei, die auf einem Server abgelegt ist, lesend zugreifen?

In dem App, welches auf den Rechnern läuft, wurde die TMemIni-Komponente verwendet.

Falls es zu Problemen kommen kann, wie kann man das geschickt abfangen?

Noch ein kurze Information zur Systemumgebung:
- auf den Rechnern läuft teilweise WinXP (SP3) oder Win7
- Es kann durchaus möglich sein, dass ca. 30-60 Rechner gleichzeitig gestartet werden (Arbeitsbeginn). Da die Anwendung im Autostart liegt, würde dann auch so ziemlich zeitgleich ein Zugriff der Rechner bzw. der gestarteten Anwendung auf diese ini-Datei auf dem Server erfolgen.

LG, Jean

[Dalai]

Solange die Zugriffe tatsächlich nur lesend stattfinden, sehe ich nicht wirklich Probleme. Kritisch wird es, wenn irgendein Schreibzugriff stattfindet, während andere zeitgleich daraus lesen. Unabhängig davon ist vielleicht die Wahl einer INI nicht unbedingt passend für solche verteilten Anwendungen, eine Datenbank kann hier durchaus Vorteile haben.

MfG Dalai

[sx2008]

Zitat von Jean:

...wenn eine Anwendung, die auf ca. 200 Rechnern in einem Netzwerk läuft

Du wirst bestimmt Einstellungen auf unterschiedlichen Ebenen haben:

• Systemweit (zentral gespeichert)
• pro Rechner
• pro User

Ich würde mal damit beginnen die Einstellungen auf diese Ebenen aufzuteilen.

[Jean]

Hallo und danke für die Antworten,

@sx2008: Einstellungsparameter sind dort nicht hinterlegt. Hier werden Informationen hinterlegt, die auf allen Rechnern erscheinen sollen (ähnlich eines Messengers, aber halt nur in eine Richtung).

@dalai: Für eine Datenbank-Anwendung ist dieses App zu klein. Aber ich werde es auf jeden Fall in Erwägung ziehen, vor allem wenn es darum geht, eventuell noch weitere Funktionalitäten zu integrieren.

Der Zugriff ist wirklich nur lesend, da ich im Vorfeld schon prüfe, ob die Datei existiert.

LG, Jean

[hoika]

Hallo,

< Der Zugriff ist wirklich nur lesend, da ich im Vorfeld schon prüfe, ob die Datei existiert. >

Was hat "Datei existiert" , mit Lesezugriff zu tun ?

Stell einfach sicher, dass deine App wirklich keinen Schreibzugriff auf die Ini macht,
dann ist es OK.


Heiko

[rwalper]

Hallo,

ich verwende auch Ini-Dateien zum Speichern von zentralen Einstellungen. Dabei konnte ich die Erfahrung machen, dass Ini-Dateien, auf denen häufig zugegriffen wird, Probleme in einem reinen SMB2-Netzwerk bereiten können (nur Rechner mit Windows Server 2008 und Windows Vista aufwärts, kein einziger mit Windows XP!).

Bei SMB2 werden Dateien auf SMB-Freigaben 10s standardmäßig gecached. Das soll so sein, Performance etc., und ist nur abschaltbar, wenn man SMB2 deaktiviert.

Bei Ini-Dateien, die nur selten gelesen werden, ist das kein Problem. Ich hatte aber eine Ini auf einem Server 2008, in der zentrale Programmeinstellungen gespeichert wurden und die häufig gelesen wurde. Hier gab es massive Probleme. Einzelne Ini-Zugriffe dauerten sehr lange. Das ganze Programm lief in Zeitlupe, die Processorlast ging hoch. Über den ProcessMonitor von SysInternals konnte man sehen, dass massenhaft Zugriffe auf diese Ini-Datei stattfanden, auch dann wenn im Programm gerade keine Ini-Zugriffe stattfanden.

Wenn man dann aber auf allen anderen PC's diese Anwendung minimiert hatte, lief wieder alles einwandfrei. Sowie man nur auf einem einzigen PC diese Anwendung wieder als Fenster öffnete (ohne irgendwas zu tun) lief wieder alles in Zeitlupe.

Ich weiß nicht, ob es ein Bug im SMB2-Client-Cache ist(oder war) oder ob nicht irgendeine andere Systemeinstellung damit zu tun hatte (Virenscanner waren alle aus).

Ich habe nun statt einer Ini-Datei eine XML-Datei verwendet (Zugriffe über TXMLDocument). Seitdem läuft es bei allen Kunden stabil.

Gruß

[tgvoelker]

Solange Du nicht schreibst, ist alles in Butter. TIniFile.Read... ruft Windows API-funktionen auf, ReadString z.B. GetPrivateProfileString.

Allerdings kommt es für den Fall gleichzeitigen Lesens/Schreibens ggf. zu Deadlocks. Das liegt daran, daß die Windows-API beim Zugriff auf INI-Dateien augenscheinlich kein Locking implementiert, Du diese Locks also selbst setzen müßtest, z.B. indem du die INI-Datei als Filestream mit ShareDenyWrite zum Lesen öffnest und wieder zumachst, wenn Du Deine Werte gelesen hast.

Zum Thema:
http://web.archive.org/web/200803080.../06/68152.aspx