technology:reservationpattern
Differences
This shows you the differences between two versions of the page.
|
technology:reservationpattern [2013/03/06 15:26] rtavassoli created |
technology:reservationpattern [2013/03/06 16:08] (current) rtavassoli [CAP] |
||
|---|---|---|---|
| Line 22: | Line 22: | ||
| - Rechne die 100 Zeitdatensätze ab, | - Rechne die 100 Zeitdatensätze ab, | ||
| - Wenn irgend ein Prozessschritt fehlschlägt, entferne die Sperren in den bereits gesperrten Zeitdatensätzen. | - Wenn irgend ein Prozessschritt fehlschlägt, entferne die Sperren in den bereits gesperrten Zeitdatensätzen. | ||
| + | Jetzt muss nur noch der Begriff //Sperren// definiert werden. Aktuell((PRO•M Delphi)) gibt es keine allgemeinen Sperren, sondern die bereits erwähnte explizite Sperre weil der Zeitdatensatz abgerechnet wurde. Es spricht aber nichts dagegen, allgemeine Sperren in Aggregates einzubauen. Man muss in die Sperre lediglich eine Referenz auf das dafür verantwortliche Aggregate schreiben, z.B. { Type=Invoice; Id=1234-ABCD-5678-EFGH }. Ein Übersetzer kann im UI daraus eine entsprechende Information machen, z.B. "Gesperrt weil abgerechnet". | ||
| + | \\ \\ | ||
| + | Damit die Konsistenz wirklich sicher gestellt ist, dürfen nur ganz bestimmte Prozesse autorisiert sein, Sperren zu schreiben. Da die Entitäten verteilt liegen können, muss das über die Authentifizierung laufen. Ein Prozess muss sich somit über seine Anmeldedaten eindeutig zu erkennen geben, und die Zugriffskontrolle muss darauf prüfen. Ansonsten könnte jeder beliebige Client Sperren in Entitäten löschen, was dazu führen könnte, dass sie die Konsistenz des Systems nicht mehr schützen. | ||
| + | \\ \\ | ||
| + | Die Entität muss Sperren natürlich respektieren. Es muss klar definiert sein, was die Sperre bedeutet. Z.B. dass ein Zeitdatensatz nicht mehr verändert werden darf - sein Status jedoch schon! Bedeutet es auch, dass er kein (weiteres) mal abgerechnet werden darf? Nicht, wenn die Sperre aus einem anderen Grund gesetzt wurde. D.h., dass beim Abrechnen noch eine Rolle zum Zeitdatensatz geschrieben werden muss, in die rein geschrieben werden kann, ob der Zeitdatensatz abgerechnet wurde oder nicht. Diese Rolle kann in einem ganz anderen Kontext liegen, hat mit der Sperre an sich gar nichts zu tun, das sind zwei unterschiedliche Aspekte. | ||
| + | ==== CAP ==== | ||
| + | Das Reservierungsmuster ist dafür da, das C((Consistency)) im CAP zu erhöhen, wodurch das A((Availability)) reduziert wird. Interessanterweise bleibt das P((Partitionstoleranz)) dadurch unverändert hoch, obwohl gerades das P wohl niemals Relevanz haben wird. Die Sache ist aber die, dass ich das Reservierungsmuster durch in-memory Event-Handler umsetzen kann, die Sagas simulieren. Dadurch kann in einer nicht-verteilten Umgebung C hoch gehalten werden, gemeinsam mit A, weil P nicht gegeben ist. Erst beim Partitionieren wird A reduziert, indem aus den in-memory Eveng-Handlern echte Sagas werden. | ||
| + | \\ \\ | ||
| + | D.h., das ich einen Weg gefunden habe, C und A hoch zu halten solange das System nicht partitioniert wird. Wird es doch partitioniert, müssen die Prozesse nicht verändert werden((Lediglich anders umgesetzt)), und da ich nicht auf die Konsistenz verzichten will, muss das Antwortzeitverhalten halt ein wenig leiden. | ||
| + | |||
technology/reservationpattern.1362580019.txt.gz · Last modified: 2013/03/06 15:26 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
