shownotes

Jürgen Höller - Spring 3.1

  • Spring 3.1-GA kommt im Dezember; abgestimmt auf den Technology-Snapshot 2011
    • JavaEE-6-Server (Glassfish 3, JBoss 7, Webshere 8)
    • Tomcat 7
    • Cloud-Provider wie Goggle, Amazon, VMware
  • Environment abstraction, environment profiles
    • Dieselbe Bean wird mehrfach (für unterschiedliche Umgebungen definiert), sodass die Applikation z.B. sowohl auf einem EE-Server als auch unter Tomcat deployt werden kann
    • “beans” Tag kann geschachtelt werden
  • Java-based application configuration: @Configuration um XML-Namespace-Funktion erweitert (z.B. @EnableTransactionManagement)
  • Cache abstraction – deklaratives Caching (@Cacheable, @CacheEvict; Ausführung durch Interceptor)
  • Servlet 3.0: WebApplicationInitializer – kann das web.xml ersetzen
  • JPA: Package scanning ohne persistence.xml (wenn es nur eine Persistence-Unit gibt) - LocalContainerEntityManagerFactoryBean

Sidenote: Hauptmotivation für Upgrade auf Java 7 ist die VM-Performance

Spring 3.2: Hauptthema Java EE 7 (JCache, JMS 2.0, JPA 2.1…)

Jürgen Höller - Komponentendesign mit Spring

  • Bootstrapping ohne XML: AnnotationConfigApplicationContext
  • Annotations sollen beschreibenden Charakter haben. Eigene Stereotypes schreiben, um Wiederholung von Annotations (@Service, @Transactional) bzw. Annotation-Parametern zu vermeiden.
  • @Autowired bei Constructors!
  • Factory-Methoden (@Bean) dürfen in beliebigen Komponenten vorkommen (d.h. nicht nur bei @Configuration, sondern z.B. auch bei @Service)
  • @Primary (z.B. statt immer denselben Qualifier) verwenden
  • Configuration classes (@Configuration): Sammlung von @Bean-Methoden. Querverweise sind erlaubt!
  • javax-Annotations können statt Spring-Annotations verwendet werden (z.B. @Inject statt @Autowired)
  • Expression language: Expressions (“#{…}”) werden dynamisch ausgewertet (im Unterschied zu Placeholdern “${…}”)
  • @Scheduled

Keynote: Stephen Burton - The New Generation of Enterprise Java

  • Design for Failure
  • Enge Zusammenarbeit zwischen Dev und Ops (Bsp. Monitoring)

Sandro Guglielmin - Managing Java Applications in Production

Steps for dealing with a (performance) problem in production:

  1. Visualize the (distributed) Application and Business Transaction
  2. Identify what is abnormal – focus there when optimizing (no premature optimization)
  3. Track the business transaction flow – isolate where to optimize
  4. Look at diagnostics for the slow transaction (e.g. method execution times – Ops must deliver this!), optimize
  5. Verify optimization

(schwache Session: mostly common sense, könnte man auch in 5-10 Minuten vermitteln)

Michael Plöd JPA/Hibernate Performance Tuning

  • Immer aktuelle JDBC-Treiber verwenden
  • Fetching-Strategien:
    • Batch fetching (auf Entität-Ebene): @BatchSize (entschärft N+1-Problem)
    • Subselect fetching (auf Collection-Ebene):
      @Fetch(FetchMode.SUBSELECT)
    • Eager fetching: nie bei mehr als einer Collection pro Entity! Am besten in Mappings für Collections gar nicht verwenden! (nur bei Queries)
  • Caching
    • Bei Massenverarbeitung (Batches) regelmäßig flushen und clearen! (weil: First-Level-Cache ist in der Verantwortung des Entwicklers)
    • @Cache, @Cacheable
    • Collection-Cache cacht nur die Primary Keys
    • verteilte 2nd-Level-Caches nur von (Caching-/Netzwerk-)Spezialisten aufsetzen lassen!
    • immer equals() und hashCode() implementieren!
    • Cache konservativ konfigurieren (nur unkritische Entities mit vielen Reads, wenig Writes)
  • Abfragen
    • früh einschränken, Projektionen verwenden
    • immer Bind-Variablen verwenden!
    • Query-Cache wird sehr selten benötigt

Keynote: Kevlin Henney - Cool Code

Funny.