Inoffizielles deutsches Xbase-Forum

Ich muß gestehen, das ich die Web-Version der NG nicht mag. Unübersichtlich, sperrig zu bedienen, grottenlangsam.

Aber klar, immer noch besser als garnichts. Ich mach das aber auch immer über meinen Thunderbird. Das klappt inzwischen ganz gut.

Jan

Hallo

irgendetwas scheint mit den DataObjects() doch nicht zu stimmen. Meist geht ja die neuzuweisung eines solchen nach dem neuladen einer DLL wie ich weiter oben schrieb.

Oft ergibt sich aber auch "Interne Datenstructuren zerstört"

oSessionData := nil
oSessionData := Dataobject():new() --> Hier knallts, Thread abgebrochen. Danach kann kein Thread diese Zeile mehr ausführen bezw. an die oSessionData Public Variable ein neues Object zuweisen. Nach Neustart läufts erneut.

Gruss Carlo

Hallo Carlo,

die Meldung kenn ich leider auch zur Genüge, zum Glück mit abnehmender Tendez. Aber bislang noch nie im Zusammenhang mit DataObjects.

Jan

Guten Morgen

benutzt jemand DataObjects erfolgreich Lesend und Schreiben in mehreren Threads?

Alle im laufe des Programmablaufs wechselnden Daten habe ich in Datenbanken verfrachtet. Und dann Ruhe gehabt.
Viele Angaben die sich nie ändern und häufig benutzt werden halte ich noch immer in einem Dataobject vor.

Seit einiger Zeit habe massenhaft abgestorbene Threads beim Zugriff auf DataObjects.

In diesen Fällen lässt sich die EXE dann nicht mehr beenden. Mit Taskmanager kann "Prozess beenden" gewählt werden, das schliesst das Programmfenster der Prozess der EXE bleibt aber bestehen und kann nur durch einen Neustart des Rechners "gekillt" werden.

Hat AGP doch recht mit seiner Aussage dass die DataObjects nicht Threadsave sind?

Cu Carlo

Moin Carlo,

ich arbeite in verschiedenen Projekten teilweise intensiv mit Threads. Und mit DataObjects sowieso. Und hatte bislang noch keinerlei Probleme mit dieser Zusammenstellung.

Jan

Hallo Jan

hast du die DataObjects dann lokal in einem Thread oder benutzt du ein globales DataObject lesend und schreiben gleichzeitig aus MEHREREN Threads?

Cu Carlo

Hallo Carlo,

bislang nur lokale DataObjects. Ein PUBLIC möchte ich mal später einführen für programmweite Vorgaben. So weit bin ich aber noch nicht.

Hast Du das Problem mit lokalen oder systemweiten DataObjects?

Jan

Wenn man nur lesend auf eine Public / private zugreift, sollte das auch aus Threads funktionieren,
aber niemals sind die dafür gedacht automatisch konkurierende Schreibzugriffe auszuhalten, das gilt auch für DataObjects.
Um das zu gewährleisten müsste man Sperrmechanismen einführen, die Geschwindigkeit kosten würden (ähnlich DBF exclusive gegen shared geöffnet ...).

Wenn an sowas machen will, muss man sich eine Klasse schreiben, die die Zugriffe hintereinander legt, siehe dazu

SYNC
Declares a method which is synchronized across any number of threads

Hallo Jan

mein Problem ist mit systemweiten Dataobjects in einer Public Var.
Beim Anlegen des Objects schreibe ich alles benötigte rein, danach LESE ich nur noch.

Ich bin jetzt am umschreiben, mache aus dem DataObject eine Klasse mit Klassen Vars und teste erneut.

Gruss Carlo

ramses hat geschrieben: ↑Mo, 23. Jul 2018 9:43 Hallo Jan
mein Problem ist mit systemweiten Dataobjects in einer Public Var.
Beim Anlegen des Objects schreibe ich alles benötigte rein, danach LESE ich nur noch.

Sind Publics nicht Thread-Local ?

Ich nutze für solche Aufgaben eine Funktion mit STATIC Variable, bei einfachen Strings ist es einfach, aber es sollte auch bei Objekten gehen, da diese ja immer per Referenz übergeben werden ...
wenn man ein Objekt zurück bekommt, sollte das immer eine gültige Referenz auf das Original sein, Zuweisungen sollten also möglich sein, Lesen auf jeden Fall.

Nein, PUBLICs sind global und in allen Threads sichtbar.

Und ich bin mir sicher, dass hier ein ganz anderes Problem vorliegt als eine vermeintlich fehlende Thread-Sicherheit von DataObjects.

Beim Lesen kann ich es mir auch nicht vorstellen

Hallo Tom

Und ich bin mir sicher, dass hier ein ganz anderes Problem vorliegt

Ja, nur welches? Hättest du dazu auch einen Tip?

Irgendwo muss ich ja mal was ändern um weiterzukommen.

Gruss Carlo

Hallo, Carlo.

Zum Verständnis.
Du erzeugst globale DataObjects. Dann gibt es von Dir erzeugte Xbase-DLLs, die zur Laufzeit geladen werden, vermutlich in einem Serverkontext. Bis dahin geht alles fein. In diesen DLLs werden die DataObjects u.U. manipuliert, also ergänzt. Jetzt tritt eine Änderung ein, die das Rekompilieren der DLLs auslöst, und danach sind die DataObjects weg? oder defekt? oder wieder auf dem vorigen Stand? Ist das irgendwie das, was Dich umtreibt?

Hallo Tom

die Sache mit den Xbase-DLL's verwende ich nur zum Entwickeln der Ajax-Antworten in einem Serverkontext. Das fertige Programm ist mit allem als eine EXE gelinkt. Ich habe in einem vollständigen Programm keinen Code in eigenen Xbase-DLL's.

Seit ich begonnen habe DataObjects einzusetzen habe ich Fehler die ich früher gar nicht kannte. Und das Ausmass wird immer mehr.
Aktuell löst der Programmstart das erstellen und befüllen des Globalen DataObjects aus. Ist dieses erstellt werden die darin enthaltenen Vars nur noch von den verschiedenen Thread gelesen. z.B. a := oData:www_Path

Das Problem ist nun dass dies eigentlich sehr gut funktioniert sich aber im laufe von Stunden immer mehr Thread's einfach Aufhängen und das Programm nur noch durch einen Neustart des Rechners beendet werden kann. Auf dem Client zeigt sich ein gehängter Thread höchstens durch den Hinweis "Keine Verbindung zum Server" durch erneutes Klicken wird dann einfach ein neuer gestartet und alles läuft weiter ...

Das von dir erwähnte Problem beim Test bezw. Rekompilieren während der Entwicklung habe ich in den Griff bekommen indem ich zuerst das Object zerstöre und dann neu aufbaue.

Gruss Carlo

Hallo

DataObjekte aus der App entfernt und damit die Probleme auch.

Gruss Carlo