Hallo,
Es wäre schön, wenn ich Dich mit Namen ansprechen könnte. Ein sinnvoller Absender und eine Grußformel an Ende wäre dabei hilfreich.
Hab mein Profil mal angepasst, aber keine Ahnung, ob und wann das auf das Forum durchschlägt.
Ich würde das nach Möglichkeit entkoppeln und per Scheduler synchronisieren. Eine Synchronisation zur Laufzeit mit gleichzeitigem lokalem persistenten Model ist keine gute Idee, dann machst Du alles von Hand. Angefangen damit, dass Du Dir überlegen musst, welcher dieser Requests jetzt diese Daten aktualisieren muss und welche nicht. Sprich: Du musst Dir bei jedem Objekt das „last synced" merken um zu entscheiden, ob das zu synchronisieren ist oder nicht. Natürlich hat der Datensatz bereits das Attribut „tstamp" womit die letzte Modifikation in der Datenbank gemeint ist. Aber dieser tstamp gehört ja eigentlich nicht in deine Domäne. Das ist ein Hilfsmittel, ein Werkzeug. Ein eine Object-Property des Extbase Domain-Models würde ich den tstamp nicht mappen solange er nicht wirklich im Frontend für den Benutzer als „letzte Änderung: Vor 15 Minuten" o.ä. angezeigt werden soll. Wenn Du die Synchronisation in einen Scheduler packst ist klar: Jedes Mal wenn der läuft synchronisiert der.
Aber wie mache ich es dann? Ich muss ja irgendwie aus der XML-Antwort meine Objekte basteln, über die ich dann im Fluid Template iteriere und die Tabellen zusammensetze.
Die Aufteilung in den Teil der sich geändert hat und den Teil der sich nicht geändert hat kannst Du im Scheduler immer noch durchführen. Lass Dir eine Liste aller Objekte geben, evtl. mit reduziertem Datenumfang. Diejenigen die im SOAP-Request ein Änderungsdatum neuer als tstamp lokal haben sind lokal zu aktualisieren. Die die im SOAP-Request ein Änderungsdatum älter als tstamp haben kannst Du in Ruhe lassen. Die die lokal existieren aber nicht über den SOAP-Request kommen musst Du lokal löschen. Insbesondere die Entscheidung welches Objekt ggf. zu löschen ist kannst Du nur über Bande treffen wenn Du im Controller des Frontend-Requests synchronisierst.
Leider liefert der Webservice kein Änderungsdatum o.Ä. an dem ich entscheiden könnte, ob aktualisieren, nicht aktualisieren oder löschen. Bleibt also nichts anderes übrig als lokal zu entscheiden mittels timestamp, oder?
Weiterhin bringt Dir bei der Synchronisation im Frontend die Extbase-Persistenz eigentlich keinen relevanten Vorteil. Wenn Du stattdessen den Plugin eine Stunde lang als HTML-Snippet cachen kannst, genügt es, die Objekte oer SOAP zu holen, an Fluid zu übergeben und nach dem PHP-Request wieder zu vergessen. Der dritte, weit schlimmste Nachteil der Synchronisation im Controller ist, dass Du Deine Frontend-Laufzeit von fremden Servern abhängig machst. Wenn der SOAP-Server mal nen schlechten Tag hat und ein paar Sekunden für die Antwort braucht, oder gar nicht antwortet, weil irgendwas hängt, dann hängt auch Dein Frontend. Solange Du Deine Daten nicht in der Datenbank als geändert schreibst (sprich: die Nicht-Antwort des SOAP-Servers als leeres Result und damit Löschanweisung interpretierst) bedeutet das für Dein Frontend, dass mehrfache Anfragen im Frontend jeweils parallel auf die Idee kommen, für die Synchronisation zuständig zu sein, und alle hängen am hängenden SOAP-Server fest. Dein Webserver hat ja nicht unendlich viel Arbeitsspeicher und kann damit nicht unendlich viele PHP-Prozesse gleichzeitig bedienen. Wenn Du für das Betriebssystem 1GB RAM abziehst und jedem PHP-Prozess 64MB RAM spendierst kansnt Du Dir ausrechnen, wie viele parallele PHP-Prozesse Du Dir erlauben kannst ohne dass der Server swappen muss. Die Zahl liegt mit großer Wahrscheinlichkeit im unteren zweistelligen Bereich. Wenn die Seite mit der Tabelle jetzt etwas Load hat, vielleicht vom ein oder anderen Crawler gefunden wird, wenn Du jetzt auch noch ungeduldige Webseitenbesucher hast die nach 10 Sekunden Ladekringel gleich auf reload drücken, dann hast Du sehr schnell alle Deine PHP-Prozesse damit belegt, auf den nicht mehr reagierenden SOAP-Server zu warten. Ab diesem Zeitpunkt sind Frontend und Backend nicht mehr erreichbar.
Da hast du natürlich recht. Ich werde also die getrennte Lösung per Scheduler vorziehen. Gruß, Fabian _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
