Daten-Synchronisation Client <-> Datenquelle (DB) ?

[AlArenal]

Moinsen!

Folgende Situation:
Eine Client-Anwendung liest und schreibt seine Daten aus einer Datenquelle. In der Anwendung kann folgendes passieren:

- Daten werden geändert (aus der Datenquelle gelesene Daten wurden geändert und müssen zurückgeschrieben werden)
- Daten werden gelöscht (aus der Datenquelle gelesene Daten wurden gelöscht und müssen nun aus der Datenquelle entfernt oder dort archiviert werden)
- Daten werden erzeugt (der Client erzeugt neue Daten, die in die Datenquelle eingefügt werden müssen)
- Daten bleiben wie sie sind (Daten aus der Datenquelle werden nicht verändert)

Faktisch startet eine Anwendung und lädt benötigte Daten, in meinem Fall kommen sie aus einer SQL-Datenbank und werden via XML-RPC transferiert. Meine Denksportaufgabe ist wie ich die Daten in der Anwendung und der Datenbank synchron halte, dabei ist vereinfacht eine Sngle-User-Umgebung anzunehmen (der Multi-User-Fall wird durch Locking ausgeschlossen).

Meine bisherigen Überlegungen:
Im Grunde müsste ich für meine Datenobjekte sowas wie eine zantrale Verwaltung (Liste o.ä.) haben. Beim Speichern der Daten aus der Anwendung würde ich die Liste durchgehen, das Datenobjekt untersuchen und entsprechend agieren. Dazu wäre es vermutlich am praktischsten diese Objekte über eine Factory zu erzeugen. Jedes Datenobjekt müsste ein Interface implementieren, über das ich setze und abfrage ob die enthaltenen Daten mit der Datenquelle synchron (INSYNC) sind, zu löschen sind (DELETE), neu sind (NEW) oder sich geändert haben (CHANGED).

Problem:
a) Ein Datenobjekt mit Daten aus der Datenquelle wird im Programmverlauf auf null gesetzt. So hab ich keine Möglichkeit mehr nachzuvollziehen um welche Daten es sich handelte und ob und wie ich sie in der Datenquelle behandeln soll. Ich kann mir ne Richtlinie ausdenken um diesen Fall abzufangen, aber das ist macht die Implementierung unnötig komplex und fehleranfällig. Schön wäre es wenn das Programm selbst daraus resultierende Probeme abfangen könnte.

b) Mein Java Patterns Workbook ist gerade nicht bei der Hand

Da es sich um ein Problem handelt, das so ziemlich jede Datenbankanwendung hat, muss es da doch Erfahrungswerte und empfehelnswerte Lösungswege geben. Entweder hab ich aber gerade ein Brett vorm Kopf oder .. oder nicht..

Eben kam mir noch die Idee statt einer Liste meine Datenobjekte nochmals zusätzlich in ein Objekt zu packen und dies stattdessen in die Liste zu setzen. Würde das Datenobjekt ge-nullt, wäre das Wrapper-Objekt noch intakt und darin würde ich noch Meta-Infos ablegen um die Beziehung Datenobjekt->DB-Daten herstellen zu können.

Vielleicht hat hier ja wer die eine oder andere Anregung. Googel liefert zu den passenden Stichworten alles, nur nichts zu diesem Thema..

 

[Bleiglanz]

a) organisiere dir eine Zentrale Map, über du die jedes DB-Objekt per PK und tabellenname finden kannst (dann macht es nichts, wenn irgendwo was =null gesetzt wird)

b) solltest du aber

Fowler: Patterns of Enterprise Application Architecture

da steht das alles drin und es werden verschiedene Varianten diskutiert

alternativ: Hibernate, nimmt dir den ganzen Schmonzes ab

 

[Guest]

Was Du suchst, ist eigentlich etwas ähnliches wie Entity-Beans, nur clientseitig.
Was spricht dagegen Informationen über den Zustand der Daten zu verwalten?
z.B. INSERTED, CHANGED, DELETED (als Attribute der Datenobjekte)
Du kannst dann die Daten anhand dieser Informationen unterscheiden
und entsprechend reagieren bzw. geänderte, neu eingefügte oder gelöschte
Daten auf einen Schlag mit der Datenbank abgleichen, in der Anzeige
hervorheben/filtern usw.
Das alles ist noch dadurch vereinfacht, dass Du keine Mehrbenutzerumgebung
hast und Dich nicht um Änderungen an anderen Arbeitsstationen kümmern
musst.

 

[AlArenal]

a) organisiere dir eine Zentrale Map, über du die jedes DB-Objekt per PK und tabellenname finden kannst (dann macht es nichts, wenn irgendwo was =null gesetzt wird)

Hab nun folgende Pen&Paper-Arbeitsversion:

interface DataChangedObservable:

• addDataChangedObserver(DataChangedObserver)
• removeDataChangedObserver(DataChangedObserver)
• notifyDataChanged()

interface DataChangedObserver:

• dataChanged(DataChangedObservable)

class DataObject:

• enthält Referenz auf ein DataChangedObservable
• implementiert DataChangeObserver
• enthält Meta-Infos für das Objekt (DB-Tabelle, PK, Änderungs-Status, ...)

class DataFactory:

• implementiert als Singleton
• get-Methoden für meine Objekte
• führt intern eine Map
  [list:1095fe67e3]
• legt jedes erzeugte Objekt in ein DataObject ab

[/list:u:1095fe67e3]

Öhm.. hoffe ich hab das mal eben so richtig hingeklatscht.

Meine Objekte sollen nun im Grunde ihr DataObject bei Änderung benachrichtigen und dieses ändert dann entsprechend seine Status-Informationen. Speichere ich den Krims am Ende ab, durchlaufe ich meine Map mit den DataObjects und lese aus welche Daten in der DB ich anlegen, ändern oder löschen muss...

Hm.. nun habe ich doch für jedes Objekt noch eins angelegt und beide miteinander verschweißt. Naja, wenn es sich nicht vermeiden lässt...

b) solltest du aber

Fowler: Patterns of Enterprise Application Architecture

da steht das alles drin und es werden verschiedene Varianten diskutiert

Ich hab das hier. Muss es nur mal wieder den Klauen anderer entreißen..

alternativ: Hibernate, nimmt dir den ganzen Schmonzes ab

Soweit ich weiß aber nur wenn direkt auf DB gearbeitet wird und ich muss über den Umweg XML-RPC gehen (Kunden-IT kriegt graue Haare wenn intern Ports auf die DB freigeschaltet werden sollen).[/list]

 

[AlArenal]

Was Du suchst, ist eigentlich etwas ähnliches wie Entity-Beans, nur clientseitig.

Mag sein, mit EJB hab ich mich nie beschäftigt

Was spricht dagegen Informationen über den Zustand der Daten zu verwalten?
z.B. INSERTED, CHANGED, DELETED (als Attribute der Datenobjekte)

Die Idee hatte ich auch. Anders lässt es sich im Grunde ja auch nicht handhaben.

Du kannst dann die Daten anhand dieser Informationen unterscheiden
und entsprechend reagieren bzw. geänderte, neu eingefügte oder gelöschte
Daten auf einen Schlag mit der Datenbank abgleichen, in der Anzeige
hervorheben/filtern usw.

Hm.. müsste ich aus meiner im vorigen angedachten Observer-Observable-Beziehung eine feste 1:1-Beziehung machen. Dann wäre das grundsätzlich drin in der Anwendung auch den Status irgendwo unterzubringen (so ich das mal bräuchte).

Das alles ist noch dadurch vereinfacht, dass Du keine Mehrbenutzerumgebung
hast und Dich nicht um Änderungen an anderen Arbeitsstationen kümmern
musst.

Es macht bei uns keinen Sinn wenn mehrere an einem Datensatz doktorn. Daher werde ich den wohl beim Laden über ein Flag und nen Timestamp in der DB sperren. Die Client-Anwendung bekommt nen Timer verpasst der periodisch den Timestamp des Locks updatet. So hoffe ich vermeiden zu können, dass jemand nen Datensatz öffnet und sie auf ewig gelockt bleibt (weil Client abschmiert oder sonstwas passiert).

 

[Guest]

Vielleicht hilft Dir das hier: http://sql2java.sourceforge.net

 

[AlArenal]

Vielleicht hilft Dir das hier: http://sql2java.sourceforge.net

Nö, weil ich keine JDBC einsetzen kann und die Daten über XML-RPC (Port 80) transferiere. Dennoch danke.