Warum man Assets ohne Protokoll ausliefern sollte

Ein bekanntes Problem beim Arbeiten mit assets ist die unterschiedliche Auslieferung via HTTP (http://) bzw. HTTPS (https://). Schon die kleinste Mischung führt zum Browserfehler und zeigt im Zweifel im Browser an, dass die Verschlüsselung nicht durchgängig ist. Will man nicht. Die Lösung für das Problem ist einfach – Assets sollten ohne Angabe des Protokoll ausgeliefert werden.

Aus

wird dann

Der größte Vorteil daran ist, dass der Browser die Assets nun automatisch mit dem Protokoll aufruft, mit dem die Webseite aufgerufen wurde.

Schaut man sich einmal ein CDN wie BootstrapCDN an, so bekommt man dort eine entsprechende URL bereits standardmäßig.

via

UPDATE
Wie auch im verlinkten Quellartikel erwähnt, hat mich Jens gerade via Twitter auf Probleme bei der lokalen Bearbeitung hingewiesen.

Jens hat natürlich recht. Für die lokale Bearbeitung ohne Webserver ist das Fehlen eines Protokolls für die Assets natürlich eher suboptimal.

Batch-Verarbeitung von Hibernate beschleunigen mit flush und clear

Vor kurzem musste ich einige Text-Dateien auslesen und den Inhalt via Hibernate in eine MySQL-Datenbank schreiben. Relativ einfache Sache, möchte man denken: Datei auslesen, die einzelnen Zeilen verarbeiten und persistieren. In Summe handelte es sich um ca. 38.000 Zeilen mit relativ einfach strukturiertem Inhalt. Der komplette Import-Prozess war schnell geschrieben, brauchte aber relativ lange bis alle Zeilen in der Datenbank gespeichert warten. Um genau sein, braucht der komplette Prozess rund 5 Minuten. Für drei Text-Dateien mit wenig Inhalt war dies definitiv zu lange. Eine erste Analyse der SQL-Statements brachte keine neuen Informationen, außer das der Prozess für die ganzen Statements wirklich 5 Minuten braucht.

Die Hibernate-Dokumentation brachte nicht nur die Lösung, sondern auch gleich das Problem zum Vorschein: You’re doing it wrong! Gleich im ersten Satz findet man den Hinweis, dass man Mist gebaut hat.

Der gezeigte Code wird im Zweifel zu einer OutOfMemoryException oder zu einer sehr sehr schlechten Performance führen. Und irgendwie sah das genauso aus, wie der Bockmist, den ich erstellt hatte.

Warum ist das so und wie kann man es besser machen?
Hibernate speichert neue Entitäten zunächst im First-Level bzw. Session- Cache zwischen. Den First-Level Cache müssen alle Anfragen an Hibernate durchlaufen, er ist obligatorisch. Innerhalb dieses Caches hält Hibernate die Objekte unter seiner Obhut, bevor es diese in die Datenbank commited. Nun ist der Cache an dieser Stelle nicht besonders groß – was er auch gar nicht sein muss – und kann nur wenige Inhalte aufnehmen. Bevor Hibernate im obigen Beispiel auch nur eine Entität an die Datenbank weiter gegeben hat, fängt es an im Speicher aufzuräumen, bis letztendlich kein Platz mehr vorhanden ist. Dieses “Aufräumen” führt letztendlich zu einem großen Performanceverlust.

Hibernate bietet nun mehrere Möglichkeit wie man die Batch-Verarbeitung beschleunigen kann, oder besser gesagt, wie man sie richtig macht. Die erste Variante ist die Definition der Batch-Size bzw. des JDBC-Batching.

Mit dieser Option erzwingt man einen commit bei einer bestimmten Anzahl von Entitäten. Beim Erreichen des Schwellwerts wird ein flush und clear ausgeführt.

Eine weitere Option ist das programmatische Ausführen eines flush und clear nachdem man eine bestimmte Anzahl von Entitäten bearbeitet hat. In meinem Fall führte die Ausführung von flush und clear zu einer erheblichen Performance-Steigerung. Der komplette Prozess dauerte anstatt 5 Minuten, nun nur noch 5 Sekunden.

Was man beim Bloggen heutzutage alles beachten muss

Als ich 2004 zum ersten Mal mit dem Bloggen angefangen habe, war die Sache an sich relativ einfach. WordPress heruntergeladen, installieren, fertig. Ich kann mich daran erinnern, dass gerade die Diskussion gestartet wurde, ob denn überhaupt und wenn ja in welcher Form Blogs ein Impressum benötigen. Aber zu diesem Zeitpunkt mit minimalistischem Aufwand ein Teil der „Blogosphäre“ zu werden stand nichts mehr im Wege.

Die Frage nach dem Impressum ist im Jahre 2013 definitiv mit einem „Ja!“ zu beantworten. Mehr noch, möchte man sich nicht in ein juristischen Minenfeld bewegen und schon gleich nach der Veröffentlichung des ersten Beitrags die erste Abnahme dem Briefkasten entnehmen (so zumindest der gefühlte Eindruck), klickt man sich besser noch eine Datenschutzerklärung und, sofern nötig, auch noch gleich den passenden Disclaimer.

In diesem Sinne: auf einen guten Neustart!

Pragmatische Ansichten zu Java und Web-Technologien.