Kennt ihr folgendes Problem:

Ein Objekt wird initialisiert.

Beim ersten Teil der initialisierung liest es einige WErte z.b. aus einem DependencyInjection-Container und registriert sich als listener. (Observer-Pattern)

Der zweite Teil der Initialisierung wird aufgrund einer ausnahme abgebrochen.

So, nu hat das ding einen undefinierten zustand und reagiert auf ereignise; solange bis der garbagecollector sich irgendwann mal begnügt aufzuräumen. Und bevor er das tut wurde vielleicht schon ein zweites objekt erfolgreich initialisiert und dann gesellen sich quasi ein einhalb objekte, die diesselben ereignise bearbeiten zu einer schönen race condition. Früher oder später muss das in die Hose gehen.

Jemand eine Idee, wie man das ganz grundsätzlich angehen könnte, das abzusichern, damit nicht das gesamtsystem auf der kippe steht?

 

Ja das Problem kenn ich.

Ich persönlich habe mir angewöhnt in solchen Fällen die Initialisierung so aufzubauen, dass das halbe Objekt sich selbst abräumt wenn etwas bei der Initialisierung schief gelaufen ist.

In deinem Fall könnte ich mir vorstellen dass du das Objekt zum schluß scharf schaltest wenn die Initialisierung erfolgreich war. Sprich dass die Events prüfen ob ein Feld "_isCreated" gesetzt ist und nur dann ablaufen.

Viele Grüße

sunspeed

Hallo karle,

karle:

Jemand eine Idee, wie man das ganz grundsätzlich angehen könnte, das abzusichern, damit nicht das gesamtsystem auf der kippe steht?

Meine Idee wäre, die Subscription 2-stufig zu realsieren (A) oder die Reihenfolge umzudrehen (B), weitere Möglichkeit wäre eine Heartbeat-Variante (C).

A: Die Subscription-Logik wird 2-stufig angeboten. Erster Schritt eine Voranmeldung, etwa so, wie es bereits realsiert wird. Der Observer merkt sich allerding auch die Subscription Uhrzeit. Bereits nach der Voranmeldung bekommt der Abonennt auch die Events zugestellt. Sollte aber nach einer konfigurierbaren Zeitspanne die Subscription nicht noch einmal bestätigt werden, dann schmeißt der Observer die Subscription wieder raus.

B: Eventuell kann man die Initialisierungsreihenfolge der Objekte so drehen, dass die Subscription erst als Letztes gemacht wird (situationsbedingt und dann auch nicht einheitlich garantiert)

C: Der Observer schmeißt ein Heartbeat Event (oder Delegate Aufruf, das ist egal), das der Client per Ereignisparameter bestätigt, die Implementierung muss dann so aussehen, dass ein Heartbeat nur dann bestätigt wird, wenn eine vollständige und erfolgreiche Initailisierung erfolgte. Ein mehrfach unbeantwortetes Heartbeat sorgt dann beim Observer für die Austragung.

Das wären jetzt meine Ideen, die vielleicht als Anregungen dienen?

Grüße
Timo

hei cool, das sind alles gute ideen.

Da kommen nämlich noch weitere fälle dazu, wie verschiedene varianten von server-eigenschaftswerte, die z.b. bei init in globalen di-containern registriert wurden. (wobei ich mir gerade überlege, ob man das überhaupt zulassen muss)

Mir ist da noch variante d eingefallen:

Try

   aObj.Init

Catch ex As Exceotion

  aObj.Terminate

  throw ex

End Try

das setzt halt voraus, dass ich mir merke, was ich alles initialisiert habe. aber ich denke mit 32 bit pro eigenschaft kommt man da weit.

der fingerklopf-fall könnte nur sein, wenn jemand auf die idee kommt, innerhalb einer lazyload-berechnungsroutine eine system-eigenschaft zu beschreiben. das kann ich nicht pauschal rückgängig mache, erscheint mir etwas abenteuerlich.