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.
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. 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. 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. Um Himmels Willen führ Kommunikation mit fremden Servern erstens mit dem geringstmöglichen Timeout durch und zweitens sofern nur irgend möglich asynchron. Beste Grüße, Stephan. Stephan Schuler Web-Entwickler | netlogix Web Solutions Telefon: +49 (911) 539909 - 0 E-Mail: stephan.schu...@netlogix.de Web: websolutions.netlogix.de ---------------------------- Neu: Wir sind Amazon Web Services Partner. Mehr erfahren: https://websolutions.netlogix.de/technologie/amazon-web-services-aws ---------------------------- netlogix GmbH & Co. KG IT-Services | IT-Training | Web Solutions Neuwieder Straße 10 | 90411 Nürnberg Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 E-Mail: i...@netlogix.de | Web: http://www.netlogix.de netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338) Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) Umsatzsteuer-Identifikationsnummer: DE 233472254 Geschäftsführer: Matthias Schmidt _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
