Laden...

Dateizugriff in ASP.Net

Erstellt von DiscMaster vor 16 Jahren Letzter Beitrag vor 16 Jahren 2.383 Views
DiscMaster Themenstarter:in
316 Beiträge seit 2006
vor 16 Jahren
Dateizugriff in ASP.Net

Guten Tag zusammen,

Ich hab mal eine allgemeine Frage: Wenn ich auf dem Server in einer Datei ein paar Infos ablege, und die von der Anwendung an verschiedenen Stellen gelesen werden, und an anderer Stelle versucht das Programm in die Datei zu schreiben, dann habe ich doch das Problem das die Datei anderweitig verwendet wird, und deshalb wird der Vorgang zurückgewiesen. Wie löst man dieses Problem am besten? (Sicherlich ist das nur ein geringes Problem, denn das auslesen oder schreiben ist ja nur ein Bruchteil einer Sekunde, zumal es nur kleine Informationen sind - Und wie hoch ist die Wahrscheinlichkeit das sich zwei Anfragen überschneiden...)

Bis jetzt habe ich das so gelöst, das ich nicht direkt in die Datei schreibe, sondern, zu erst in eine andere Datei. Dann starte ich einen Thread der die Temporäre Datei in die Eigentliche zu kopieren versucht, und bei einem Fehler nach 10ms nochmal probiert, solange bis er eben erfolgreich ist, was ja in der Regel beim ersten mal schon der Fall ist.....

Aber ist das in Ordnung so? Oder macht man das 'eigentlich irgendwie anders'?

Danke, DiscMaster.

"Flache Hierarchien schaffen! Das muss konkret nicht unbedingt etwas bedeuten, kommt aber immer sehr gut an."
Bernd Stromberg

K
124 Beiträge seit 2006
vor 16 Jahren

Hallo DiscMaster,

Bis jetzt habe ich das so gelöst, das ich nicht direkt in die Datei schreibe, sondern, zu erst in eine andere Datei. Dann starte ich einen Thread der die Temporäre Datei in die Eigentliche zu kopieren versucht, und bei einem Fehler nach 10ms nochmal probiert, solange bis er eben erfolgreich ist, was ja in der Regel beim ersten mal schon der Fall ist.....

Wieso der Umweg über die temporäre Datei? Du könntest doch in deinem Thread gleich die Daten in die Datei schreiben?

lg
martin

5.941 Beiträge seit 2005
vor 16 Jahren

Hallo DiscMaster

Den Schreibzugriff sollte man synchronisieren, damit es keine Konflikte gibt.
Stichwörter: lock / Mutex

Lies dich doch mal ein wenig ein:

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

DiscMaster Themenstarter:in
316 Beiträge seit 2006
vor 16 Jahren

feine sache, herzlichen dank

discmaster

"Flache Hierarchien schaffen! Das muss konkret nicht unbedingt etwas bedeuten, kommt aber immer sehr gut an."
Bernd Stromberg

5.941 Beiträge seit 2005
vor 16 Jahren

Hallo DiscMaster

Original von DiscMaster
feine sache, herzlichen dank

Wenn du eine gute Lösung gefunden hast, bin ich auch daran interessiert, und würde mich freuen wenn du diese dann hier kurz erläutern könntest 🙂

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

DiscMaster Themenstarter:in
316 Beiträge seit 2006
vor 16 Jahren

pauschal würde ich das mit mutex realisieren (nach meinen geringen kenntnisse müsste das gehen) aber wie genau müsste ich selbst erst ergründen, aber dazu habe ich nicht die zeit jetzt, mich hat das nur generell mal interessiert wie sowas zu handhaben ist.

"Flache Hierarchien schaffen! Das muss konkret nicht unbedingt etwas bedeuten, kommt aber immer sehr gut an."
Bernd Stromberg

341 Beiträge seit 2004
vor 16 Jahren

Kann man denn nicht einfach hiermit arbeiten?

5.941 Beiträge seit 2005
vor 16 Jahren

Hallo Fritz

Kann man denn nicht einfach
>
arbeiten?

Was hat den der Application State mit Dateizugriff zu tun?
Aber klar, den Schreibzugriff auf den Application State muss auch synchronisiert weden (lock / unlock).

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

341 Beiträge seit 2004
vor 16 Jahren

Ich glaube ich hab mich nicht zu Ende ausgesprochen: die Idee war, den ApplicationState für den Dateizugriff zu mißbrauchen:

Application.Lock();
Application["Lock"] = (!((bool)Application["Lock"]));//<----Dummy
//In die Datei schreiben...
Application.UnLock();

Weil der ApplicationState für alle Sessions und Benutzer gültig ist, oder verstehe ich was falsch? Die Idee ist aber auch, dass man dieses Konstrukt allgemein für alle kritische Codeabschnitte in ASP.NET nehmen könnte die nur sequenziel verarbeitet werden dürfen.

341 Beiträge seit 2004
vor 16 Jahren

Korregiert mich bitte, wenn ich falsch denken sollte...

5.941 Beiträge seit 2005
vor 16 Jahren

Hallo Fritz

Weil der ApplicationState für alle Sessions und Benutzer gültig ist, oder verstehe ich was falsch? Die Idee ist aber auch, dass man dieses Konstrukt allgemein für alle kritische Codeabschnitte in ASP.NET nehmen könnte die nur sequenziel verarbeitet werden dürfen.

Nein, Application.Lock/Unlock() ist nur dafür da, um einen synchronisierten Zugriff auf die Application zu haben.

Da ist nichts mit Missbrauchen.
Wieso auch, es gibt ja andere, korrekte Möglichkeiten.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

341 Beiträge seit 2004
vor 16 Jahren

Gibt es dann einen Muster/Konstrukt, den man allgemein für alles nehmen könnte?

5.941 Beiträge seit 2005
vor 16 Jahren

Hallo Fritz

Gibt es dann einen Muster/Konstrukt, den man allgemein für alles nehmen könnte?

Grossartig hab ich das auch noch nicht gebraucht.
Aber im Allgemeinen: Dateizugriff in ASP.Net (Dieser Thread, ein wenig weiter oben).

Grundsätzlich sollte es vermieden werden, direkten Dateizugriff unter ASP.NET ohne Caching! zu verwenden.
Den I/O Vorgänge können unter anderem länger dauern, oder gar Fehler hervorrufen die eine grössere Verzögerung bewirken.

Zugriff über Provider (bspw. XML) sind aber Problemlos, da diese vom Provider (bspw. XmlDataSource oä.) synchronisiert und gecacht werden.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

341 Beiträge seit 2004
vor 16 Jahren

Ich suche aber nach einen Allgmeinen Mutex-Konstrukt(nicht nur Dateizugrif) der in ASP.NET für jegliche Synchronisierung verwendet werden kann...

5.941 Beiträge seit 2005
vor 16 Jahren

Hallo Fritz

Genau Mutext oder Lock Konstrukte kann man ja allgemein einsetzten.
Oder was meinst du jetzt?

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

341 Beiträge seit 2004
vor 16 Jahren

Genau Mutext oder Lock Konstrukte kann man ja allgemein einsetzten.
Oder was meinst du jetzt?

Klar, kann man machen - dies gilt aber nur innerhalb einer Session! Der Zugriff, auf eine gemeinsame Recourse, soll aber für alle Sessions auf dem Webserver gelten und dann könnte man doch mit den Application.Lock(); arbeiten wie ich finde.

5.941 Beiträge seit 2005
vor 16 Jahren

Hallo Fritz

Du hast Recht und ich habe Mist geschrieben.
Application.Lock / Unlock lässt sich für alles verwenden.

Wenn du allerdings - aus welchen Gründen auch immer - einen anderen Locking Mechanismus benutzen willst, ist dort auch was zu beachten.

Das Lock Objekt muss anwendungsweit zur Verfügung stehen.
Um das zu erreichen, muss das Lock Objekt in einer static / shared Variable gehalten werden.
Eine solche Variable wird im Application State gehalten und ist so anwendungsweit verfügbar.

Anwendungsweit verfügbar deshalb weil ein Locking auch für den 2, 3ten Request der reinkommt, gelten muss.

bspw:

Request1: Locking erfolgt bei Dateizugriff
Request2: (Request1 ist noch nicht fertig), versucht auch ein Locking zu machen und hat (da im Application State) Zugriff auf das gleiche Lock Objekt.
[...]

So lässt sich bspw. auch ein SyncLock für ASP.NET benutzen.
Siehe:

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011