Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi EVariantArrayLockedError (https://www.delphipraxis.net/28408-evariantarraylockederror.html)

MaBuSE 24. Aug 2004 14:22


EVariantArrayLockedError
 
Hallo,

wir bekommen einen EVariantArrayLockedError in einem unserer Serverprogramme.

Weiß jemand was dieser Fehler bedeutet?
(oder wo ich dazu was nachlesen kann)

Im Google hab ich nix gefunden.

Der Fehler ist in der Unit Variants deklariert und wird in einem Thread geworfen.
Scheint also ein Sync Problem zu sein. Alle relevanten Anweisungen sind aber abgesichert.
Dieser Fehler tritt "leider" nur ca. ein bis zwei mal pro Quartal auf.

Die OH sagt:
EVariantArrayLockedError ist die Exception-Klasse für Fehler, die ausgelöst werden, weil ein Varianten-Array gesperrt oder fest ist.

Unit Variants

Beschreibung
EVariantArrayLockedError wird ausgelöst, wenn eine Operation mit einem Varianten-Array fehlschlägt, weil das Array gesperrt oder fest ist.


[edit]
Der Fehler tritt warscheinlich auf, wenn TClientDataSet.Refresh aufgerufen wird.

Diese Anweisung wird nicht über Synchronize() ausgeführt, sondern es wird ein TMultiReadExclusiveWriteSynchronizer verwendet.

Die liebe OH schreibt
TMultiReadExclusiveWriteSynchronizer dient dem Speicherschutz in einer Multithread-Anwendung.

Unit SysUtils

Beschreibung
Mit TMultiReadExclusiveWriteSynchronizer kann der Zugriff auf den Speicher in einer Multithread-Anwendung überwacht werden. Im Gegensatz zu einem kritischen Abschnitt, der alle anderen Threads am Lesen und Schreiben in den zugeordneten Speicher hindert, ermöglicht es TMultiReadExclusiveWriteSynchronizer, dass mehrere Threads gleichzeitig aus dem geschützten Speicher lesen können. Bei einem Schreibzugriff eines Thread stellt TMultiReadExclusiveWriteSynchronizer sicher, dass der Thread exklusiven Zugriff auf den Speicher hat.

TMultiReadExclusiveWriteSynchronizer kann die Ausführungsgeschwindigkeit von Anwendungen wesentlich verbessern, in denen Threads häufig Lesezugriffe auf ein Objekt oder eine Variable ausführen, aber nur gelegentlich in das Objekt bzw. die Variable schreiben.

Jeder Zugriff auf den geschützten Speicher muss in Aufrufe der Methoden BeginRead und EndRead bzw. BeginWrite und EndWrite eingeschlossen werden. Andernfalls kann es zu Konflikten zwischen den einzelnen Threads kommen.


Ich hoffe es kann mir jemand helfen
[/edit]

MaBuSE 9. Sep 2004 11:24

Re: EVariantArrayLockedError
 
Zitat:

Zitat von MaBuSE
Ich hoffe es kann mir jemand helfen

Ich habe die Hoffnung noch nicht aufgegeben ;-)
Leider konnten wir das Problem noch nicht lösen. :evil:

MaBuSE 6. Okt 2004 14:20

Re: EVariantArrayLockedError
 
Zitat:

Zitat von MaBuSE
Zitat:

Zitat von MaBuSE
Ich hoffe es kann mir jemand helfen

Ich habe die Hoffnung noch nicht aufgegeben ;-)
Leider konnten wir das Problem noch nicht lösen. :evil:

Das trifft immer noch zu :-/

MaBuSE 11. Nov 2004 15:04

Re: EVariantArrayLockedError
 
*push* Es kann mir doch Keiner erzählen, dass hier in der DP keiner Ahnung von sowas hat.

mirage228 11. Nov 2004 15:26

Re: EVariantArrayLockedError
 
Hi,

ich weiss nicht, ob es Dir hilft, aber du könntest mal Hier im Forum suchenmadexcept installieren, um so eine genau Ablaufverfolgung für den Fehler anstellen zu können.

mfG
mirage228

MaBuSE 11. Nov 2004 16:06

Re: EVariantArrayLockedError
 
Zitat:

Zitat von mirage228
ich weiss nicht, ob es Dir hilft, aber du könntest mal Hier im Forum suchenmadexcept installieren, um so eine genau Ablaufverfolgung für den Fehler anstellen zu können.

Wir haben die DebugFunktionalität von der JCL verwendet.

Damit bekommen wir einen Stack inkl. Programmzeilennr. geloggt.

Zitat:

Der Fehler tritt warscheinlich auf, wenn TClientDataSet.Refresh aufgerufen wird.

Diese Anweisung wird nicht über Synchronize() ausgeführt, sondern es wird ein TMultiReadExclusiveWriteSynchronizer verwendet
Das bringt uns aber leider nicht weiter, wir wissen nicht wo wir ansetzen sollen.
Der Fehler tritt nur sporadisch und auch nur auf dem Produktionsserver auf. (ist nicht reproduzierbar)
:evil:

Trotzdem Danke ;-)

mirage228 11. Nov 2004 16:50

Re: EVariantArrayLockedError
 
Hi,

dann könnte ich dir als "Quickn' Dirty" Lösung empfehlen, einen try..except Block darum zu bauen und bei einem EVariantArrayLockedError Error die Anweisung zu widerholen.

Ist zwar nicht schön... aber naja :?

mfG
mirage228

MaBuSE 12. Nov 2004 10:54

Re: EVariantArrayLockedError
 
Zitat:

Zitat von mirage228
dann könnte ich dir als "Quickn' Dirty" Lösung empfehlen, einen try..except Block darum zu bauen und bei einem EVariantArrayLockedError Error die Anweisung zu widerholen.

Das Ganze ist in einer Serveranwendung, die mehrere Datenbankthreads ausführt. Meine Vermutung ist, das der TMultiReadExclusiveWriteSynchronizer nicht richtig funktioniert. Wenn sich also Threads gegenseitig blockieren, bringt eine Wiederholung des Befehles nicht viel. Die Synchronisation zwischen den Threads ist vermutlich das Problem. :-(
Aber ich werde Deinen Tipp mal an den Entwickler weitergeben.

Wir testen im Moment eine neue midas.dll evtl. ist ja das Problem mit dem Update behoben.

Danke für die Antwort ;-)

jim_raynor 12. Nov 2004 11:09

Re: EVariantArrayLockedError
 
Der Fehler deutet doch darauf hin, dass auf ein Variantes Array mehrmals gleichzeit in verschiedenen Threads zugegriffen wird. So wie es aussieht ist also TClientDataSet.Refresh nicht ganz Thread sicher :(

MaBuSE 12. Nov 2004 11:54

Re: EVariantArrayLockedError
 
Zitat:

Zitat von jim_raynor
Der Fehler deutet doch darauf hin, dass auf ein Variantes Array mehrmals gleichzeit in verschiedenen Threads zugegriffen wird. So wie es aussieht ist also TClientDataSet.Refresh nicht ganz Thread sicher :(

Das ist auch meine Vermutung.
Wir warten jetzt erst mal ein zwei Wochen ob das Update der midas.dll auf 7.1.1692.668 etwas bringt.
Ich werde das Ergebnis unseres Testes dann nochmal hier Posten.

Vielen Dank für die Antworten


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:50 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz