Seven Languages in Seven Weeks


Ich bin fertig mit diesem Buch und eigentlich ziemlich zufrieden mit dem gebotenen Überblick. Ein paar Sprachen habe ich nicht so intensiv ausprobiert wie andere, aber das Interesse ist halt nicht überall gleich. Im Gesamten war es jedoch eine sehr spannende Erfahrung. Zu einer praktische Umsetzung, einer dieser Programmiersprachen, wird es wahrscheinlich nicht kommen. Auch wenn Scala, Clujure und Ruby in der JVM ausführbar sind und dort bin ich schließlich daheim.

Scala

Eigentlich hatte ich mir von Scala einen möglichen Kandidaten für ein neues Projekt erhofft. Die Aktoren, Lambdas und die anderen Kleinigkeiten gefallen mir schon, aber einen vollständigen Umstieg bei Webprojekten kann ich mir nicht vorstellen. Mit Lift gibt es zwar ein eigenes Web-Framework in Verbindung mit Scala, doch wie es mit der Verbreitung aussieht weiß ich nicht. Für Aufgaben die in den Concurrency-Bereich passen, werde ich auf jedenfall vor der Realisierung eine Lösung in Scala andenken.

Gesamt Überblick

Der Schwerpunkt dieses Buches lag sicher bei der funktionalen Programmierung und Concurrency. Wenn man die meiste Zeit mit Java arbeitet, hat man immer ein Funkeln in den Augen, wenn man die Möglichkeiten zur einfachen Funktionsweitergabe in anderen Programmiersprachen sieht. Das Konzept der funktionalen Programmierung geht natürlich weit über die Weitergabe von Funktionen hinaus, doch bei der täglichen Arbeit vermisse ich die Möglichkeit am meisten. Die größte Hoffnung zur Verbesserung dieser Situation liegt jetzt mit Java-8 endlich zum greifen nahe. Trotzdem schmerzt mich dieser Umstand, da andere Programmiersprachen derartige Konzepte schon seit Jahren im Angebot haben.

Das nächsten Buch, dass bei mir in der Warteschlange steht, entfernt sich jedoch wieder etwas von der Basis und geht mehr zur SW-Architektur/Konzeption. Auf jeden Fall bietet es nach diesen schnellen Wechsel zwischen sieben verschiedenen Welten einen willkommenen Ausgleich.

Bildquelle

Was hat sich getan?

Zuallererst wünsche ich allen Leser ein Gutes neues Jahr! Das letzte Monat zählte privat und beruflich nicht zu den ruhigsten, aber was erwartet man auch von der stillen Zeit im Jahr?

Ich war aber nicht komplett untätig, die letzten Wochen hat mich das Buch Seven Languages in Seven Weeks begleitet und beschäftigt. Bei den meisten Programmiersprachen habe ich die Aufgaben vollständig durchgemacht, auch wenn es nicht immer leicht war mit den Übungen zu beginnen.

Aktuell bin ich bei Scala angelangt. Eigentlich bin ich davon ausgegangen, mich auf mein Java-Wissen verlassen zu können. Doch durch die vielen unterschiedlichen Typen, die meistens auch noch als veränderbar und unveränderbar existieren, habe ich mehr Zeit als erwartet in der API-Dokumentation verbracht.

Bei den Arrays hatte ich auch so meine Probleme als Anfänger. Es hat ganz schön lange gedauert bis ich die Unterschiede zwischen all den möglichen Klassen im Collections-Package einordnen konnte.
Die nächsten Tage halten für mich noch einige Punkte bereit, jetzt steht noch das Kapitel “Functional Programming” am Plan.

Besonders angetan war ich von der kleinen aber doch bemerkenswerten Sprache IO. Die größte Herausforderung war, bei der Google-Suche nicht immer nur Ergebnisse zu Input/Output-API’s zu erhalten. Die Möglichkeiten Code parallel auszuführen ist mehr als einfach. Alle die von dieser Sprache noch nichts gehört haben sollten schleunigst einen Blick darauf werfen, selbst wenn die Möglichkeiten für einen praktischen Einsatz eher gering sind.

Bildquelle

Frontendentwicklung aus Sicht eines Programmierers


Ich gehe nicht so weit, die Tätigkeit eines Programmierers mit Frontenddesign zu vergleichen. Hier gibt es eine eindeutige Grenze. Programmierer stehen auf jeden Fall weit jenseits dieser Grenze. Vor allem durch den täglichen Gebrauch komplexer Anwendungen, hat sich die Sichtweise weit von der Sichtweise eines normalen Anwenders entfernt.

Meine normale Arbeitsumgebung ist die Eclips-IDE, diese IDE ist ein gutes Beispiel welches Bedienungskonzept ein normaler Programmierer als normal empfindet. Ein Spiegel davon sind auch manche Anwendungen, die im OpenSource-Umfeld zu finden sind. Mit Sicherheit verfügt eine derartige Anwendung über viele Menüs, mehrere Fenster und über ein Plugin-System.

Trotzdem benötigt jede Anwendung ein Frontend und da Programmierer fleißig sind, gibt es mehr als genug Frameworks für die Frontendentwicklung, besonders im Web-Umfeld.
Hier gibt es auch öfter einen weiteren Gedankenfehler. Im Web-Umfeld gibt es sehr viele unterschiedliche Geräte, die eine Web-Anwendung darstellen können. Wir Programmierer lieben aber Lösungen, die auf allen Geräten funktioniert. Im Optimalfall soll das Client-Framework die Erkennung und Optimierung der Darstellung auf das jeweilige Gerät übernehmen. Man kann nur hoffen, dass die Bedienbarkeit nicht auf der Strecke bleibt!

Ebenfalls sehr schmerzlich für einen Programmierer ist das Unverständnis eines normalen Benutzers gegenüber von technischen Details. Für einen Benutzer zählt meist nur das Frontenddesign und die Bedienbarkeit einer Anwendung. Kunden als Auftraggeber können natürlich noch anderen Anforderungen haben. Diese Anforderungen stehen den eigentlichen Bedürfnissen von Anwendern oft zusätzlich im Weg.

Ich selbst bin Programmierer und habe sicher schon einige Anwendungen verschuldet, die technisch Super sind, aber bei der Bedienbarkeit schwächen haben. Aber zumindest lebt die Hoffnung, dass sich in Zukunft mehr Designer für GUI und Frontend-Entwicklung interessieren und damit das Leben der Benutzer verbessern.

Bildquelle

Mehr als genug Möglichkeiten


In der SW-Entwicklung gibt es mehr als genug Möglichkeiten eine Aufgabe zu lösen. Oft müssen auch unterschiedliche Frameworks miteinander zusammen arbeiten. Dadurch gibt es sehr viele Kombinationen, die nicht zum Erfolg führen.

Um diese Komplexität zu verringern, hat sich das Konzept “Konvention vor Konfiguration” etabliert. Dadurch haben nicht nur Neueinsteiger, in die SW-Entwicklung, einen sehr großen Vorteil. Es können auch leicht Quereinsteiger, mit Basiskenntnissen des Frameworks, bei einem Projekt weiter machen, ohne vorher den gesamten Code zu analysieren.

Mir ist bewusst geworden, was für ein Problem diese große Auswahl an Möglichkeiten sein kann. In Java hat man eine riesige Auswahl von Web-Containers und Application-Server. Die Auswahl der passenden Umgebung kann eine nicht enden wollende Aufgabe sein. Alleine im NetBeans-IDE, ohne zusätzlich installierter Plugins, existiert eine riesige Auswahl von Möglichkeiten zur Projekterstellung. Berücksichtigt man die Auswahl der Maven Archetypes wird die Liste beängstigend lang.

Diese Entscheidungen können auch auf der Mikroebene bei der Auswahl des richtigen Datentype anfangen. In Java gibt es alleine für die Darstellung von Ganzzahlen vier Möglichkeiten byte, short, int und long. In den meisten dynamischen Sprachen gibt es genau einen Type für Ganzzahlen. Dieser Type verfügt meistens über einen Wertebereich, der an einen Long-Wertebereich in Java heranreicht.

Mir geht es nicht um die Diskussion dynamische vs. statische Programmiersprachen. Genügend Teams auf beiden Enden des Spektrums haben großartige Produkte umgesetzt. Es geht mir darum nachzudenken, warum es so viele Möglichkeiten gibt, ob diese Möglichkeiten mehr Fehler verursachen als sie nutzen und ob diese Möglichkeiten noch benötigt werden.

Noch eine Zugabe zum Nachdenken, ist Frontend-Design schwierig weil die Frameworks dazu ungenügend sind oder weil der Benutzer(Kunde) an dieser Stelle die meisten Änderungswünsche hat.

Bildquelle

Groovy Spock und Mocking


Ich bin jetzt schon seit Jahren Java Entwickler. Dabei startete ich im Java EE Bereich. Von da ging es ziemlich schnell zum Springframework, was im Vergleich zum Standard einen wirklich sehr leichtgewichtigen Ansatz verfolgt. Trotzdem kann ich mit Sicherheit sagen, ich habe schon mehr XML-Konfigurationsdateien geschrieben als mir lieb ist.

Mit Ruby on Rails, Grails und teilweise dem Springframework ist dazu eine eindeutige Gegenbewegung, mit dem Motto “Konvention vor Konfiguration”, entstanden. Für mich begann damit die Zeit, in der ich mit verschiedenen dynamischen Programmiersprachen und ihren Frameworks experimentierte. In meinem beruflichen Umfeld konnte ich dieses Konzept nicht wirklich zum Einsatz bringen. Die bereits bestehenden Anwendungen wirken dabei wie ein Anker der, ab einer gewissen Anzahl von Anwendungen, nicht mehr gehoben werden kann.

Begeisterung für dynamische Programmiersprachen

Die Zeit mit den unterschiedlichen Programmiersprachen war jedoch nicht umsonst. Viele Verbesserungen, in meiner Art, Programme zu schreiben wurden dadurch möglich. Einige der dort vorhanden Konzepte konnte ich auch in die tägliche Arbeit integrieren. Auch die Begeisterung für dynamische Programmiersprachen ist geblieben.

Groovy und Spock

Vor kurzen wurde ich durch einen Podcast auf das Spezifikationsframewok “Spock” aufmerksam, welches mit Groovy auf der JVM ausgeführt werden kann.
Mit diesem Test-Framework können Code-Spezifikationen erstellt werden. Spock bedient sich dabei einer eigenen Domain Specific Language(DSL), die eine sehr übersichtliche Spezifizierung von erwarteten Verhalten ermöglicht. Vor allem möchte ich damit Spezifikationen für Java-Klassen erstellen können. Als Test habe ich einige Spezifikationen gegen die JodaTime-Library erstellt. Dabei bin ich den Anweisungen auf der GettingStarted-Seite gefolgt.

ACHTUNG: Groovy 1.8.6 muss installiert sein. Keine andere Version von Groovy wird unterstützt.

Es findet sich leider keine Anleitung für die Verwendung von Maven 3, welches beim aktuellen NetBeans-IDE mit installiert ist. Nach der Entfernung des Spock-Plugins und der Umbenennung der Testklasse von “NameSpock.groovy” auf “NameTest.groovy” wurde der Testfall richtig erkannt und wie erwartet ausgeführt.

Spock Blocks

Das Hauptkonzept von Spock ist es, die einzelnen zu spezifizierenden Funktionen in Blöcke zu gruppieren. Dieses können miteinander kombiniert werden, auch können mehrere Codezeilen zu einem Block gehören.

Hier ein Übersicht aus der Spock-Wiki Seite.

Quelle SpockBasics

Das Dreamteam der Blockpaare ist:

when: // beinhält einen Methodenaufruf
then: // hier wird ein erwarteter Zustand des Objektes überprüft

Soll auf mehrere Werte geprüft werden, erfolgt dass mit einer

expect: // Methodenaufruf mit Ergebnisvergleich
where: // Angeabe von Parametern

Kombination.

Mocking

Das Spock-Framework verfügt auch über ein eigenes Framework für die Erstellung von Mocks. Die dort gebotenen Funktionen habe ich noch nicht ausprobiert, die Syntax ist jedoch einfach und sollte für die meisten Fälle ausreichend sein. Ein detailliertes Beispiel habe ich auf dieser Seite gefunden.

RSpec vs Spock

Grundsätzlich fühlt sich Groovy von der Syntax ähnlicher zu Java an als Ruby. Ruby verfügt aber ebenfalls über ein sehr gutes Tool zur Spezifizierung “RSpec”. Mittels JRuby lässt sich dieses auch nutzen. Schon vor einigen Jahren hat es mehrere Versuche gegeben, Werkzeuge aus der Ruby-Welt für Java nutzbar zu machen:

In der nächsten Zeit werde ich sicher einige Spezifikationen mit Spock erstellen, sollte sich dadurch eine Erleichterung beim testen ergeben werde ich wahrscheinlich bei diesem Framework bleiben.

Weitere Links:

WebServices als Datenbankabfragen


Ich war auf meinem zweitem Meetup. Das Thema war Ruby und Web-Developement. Ein breites Gebiet, in dem auch der Lehrplan der FH-Salzburg und deren Bemühung zur Ausbildung neuer Web-Developer seinen Platz fand. Die Gruppe war mit ca.17 Teilnehmern überraschend groß und die Organisatoren haben wirklich eine großartige Arbeit geleistet. Vor allem die Verpflegung konnte sich sehen lassen!

Beim Thema Ruby sind meine Sprachkenntnisse relativ gering und ich konnte nicht viel zum Thema beitragen. Dafür ist mir bei einer Unterhaltung die Ähnlichkeit zwischen einem WebService-Aufruf zur Datenbeschaffung und einer Datenbankabfrage richtig klar geworden. Als WebService-Aufruf bezeichne ich hier, einen Zugriff auf einen Dienst oder Anwendung über HTTP. Klassische Beispiele für WebService-Aufrufe sind SOAP und REST.

Das soll nicht heißen ein WebService-Aufruf ist gleich zu setzten mit einer Datenbankabfrage. WebService-Aufrufe haben auch eine entscheidende Rolle bei der Verteilung und Skalierung von Prozessen und sollten deshalb nicht auf Datenabfragen reduziert werden. Bei aktuellen Projekten, an denen ich beteiligt bin, wird jedoch sehr selten eine Bearbeitungen in einem anderen Systemen angestoßen. Meistens wird auf Daten aus anderen Systemen zugegriffen.

NoSQL (Not only SQL) Datenbanken bieten ebenfalls sehr häufig ein REST-API für den Zugriff und die Bearbeitung von Daten. In meiner Beobachtung sind aber auch die meisten Anwendungen schon richtige NoSQL-Datenbanken, selbst wenn sich dahinter eine relationale Datenbank verbirgt. Durch die angebotenen REST-API werden oft Funktionen einer Datenbankschnittstelle angeboten.

Tools in Java

In JavaScript  ist die Verwendung von NoSQL-Datenbanken, durch die Bereitstellung von REST-API’s mit JSON-Daten, ein logischer Schritt. Schon alleine durch die große Anzahl der Möglichkeiten(Redis, MongoDB oder CouchDB), die für JavaScript existieren, ist dieser Zusammenhang gesichert.

Im Java-Umfeld, in dem ich mich aktuell bewege, ist dieser Gedanke noch um einiges weiter entfernt. Auch das Tooling ist oft vergleichbar mit dem direkten Level von JDBC. Die Schwierigkeit besteht in diesem Fall mehr auf dem Unterschied zwischen dynamischen und statisch typisierten Daten.

Für mich war der Gedanke neu, andere haben diese Ähnlichkeiten viel früher erkannt. Im “Spring Data” Projekt wird hierfür auch schon eine Unterstützung geboten. Dort finden sich bekannte Vertreter aus dem NoSQL-Datenbanken Umfeld wie MongoDB und Redis.

Ich hatte zwar noch nicht genügend Zeit mir die Projektbeschreibungen genau anzusehen, doch werde ich mich beim nächsten eigenen Projekt darauf zurück kommen.

Bildquelle

Netzwerkproblem, erkannt durch Visualisierung


Bis vor kurzen wusste ich nicht, dass ich ein Problem mit meinem Hausnetzwerk hatte. Die Verbindung zum Internet funktionierte, das NAS war erreichbar. Nur manchmal hatte ich das Gefühl, die Verbindung von meinem PC zum NAS könnte schneller sein.

Dieses Gefühl hat sich seit der Installation von Windows 8, in eine Gewissheit verwandelt. Mit der neuen Darstellung hat man die Übertragungsgeschwindigkeit eindeutig besser im Auge.

image

Die Geschwindigkeit ist mit 11,3MB/s nicht richtig schlecht. Bei einer direkten Übertragung von PC zu NAS, wobei beide Geräte eine GBit-Verbindung haben sollten, jedoch bei weitem nicht die Obergrenze.

Die Fehlersuche war zum Glück relativ kurz. Im “Netzwerk- und Freigabecenter” unter “Status von Ethernet” wurde eine Übertragungsrate von 100MBit/s angezeigt.

image

Problembehebung

Leider gibt es die Funktion “Übertragungsrate ändern” nicht. Google hatte jedoch auf Anhieb die richtige Antwort für mich.

Die bei diversen Geräten beigelegten Kabel, sind nicht immer für GBit-Lan ausgelegt.

Daraufhin probierte ich verschiedene Kabel aus, bis ich bei der Übertragungsrate 1 GBit/s angezeigt bekam.

Die Geschwindigkeit hat sich von 11 MB/s auf 47 MB/s erhöht, damit bin ich sehr zufrieden. Bei diesem 200MB-File hatte ich fast nicht genug Zeit, um einen Screenshot zu machen. Die 5 Sekunden sind auf jeden Fall übertrieben.image

Bildquelle

Windows 8, und wie es mir gefällt

In der letzten Woche habe ich mehr Windows 8 Systeme installiert als mir lieb war. Eigentlich interessieren mich Betriebssysteme nicht wirklich, solange alle Anwendungen ohne Probleme funktionieren. Aber durch einen Hardwarefehler, bei meinem PC, wurde ich praktisch dazu gezwungen.

Warum ist jetzt alles anders?

Der erste Eindruck war sehr befremden. Details wie das Ausschalten des Computers, Vollbildanwendungen, Menüleisten am linken bzw. rechten Rand und das Fehlen des Windows Media Centers haben mich an der Entscheidung Windows8 zu wählen zweifeln lassen. Jetzt nach einer Woche sehe ich alles viel entspannter.

Mittlerweile überwiegt die Begeisterung

Das Bedienkonzept der Vollbildanwendungen wurde schnell zur Gewohnheit. Der größte Vorteil entsteht jedoch durch die gesteigerte Geschwindigkeit. Die Performanz ist eine dieser Features, die man selbst oft nicht benennen kann, aber bei der Nutzung einen entscheidenden Unterschied macht. Ich habe nie gemessen, wie lange mein PC zum starten braucht, trotzdem verwende ich seit der Neuinstallation mit Windows8 den PC um ein vielfaches öfter.

Datensicherung

Mit Windows8 wurde der Dateiversionsverlauf eingeführt, hier hätte ein Marketingname wie bei Apples “TimeMaschine” nicht geschadet, funktionieren tut aber alles bestens.

Starten kann man, mit einer Suche nach “Backup” oder “FileHistory”. Im Standard ist der Verlauf nicht aktiviert. Deshalb sollte man unbedingt als erstes eine externe Festplatte anschließen und den Verlauf aktivieren.

image

Durch den Dateiversionsverlauf werden für alle Dateien, innerhalb der Bibliotheken(Bilder, Musik, … ), Dateiänderung in den Verlauf gespeichert.
In der Ansicht für die FileHistory wird auch ein Link zur “Systemimage”-Erstellung und zur Erstellung eines Reparaturdatenträgers angeboten.

Die unterschiedlichen Dateiversionen können auch sehr einfach wieder angezeigt werden. Dazu im Startmenü wieder “FileHistory” eingeben und es werden schon alle gesicherten Bereich angezeigt.

image

Systemimage

Innerhalb der Ansicht werden auch weitere Links, darunter auch zur “Windows 7-Dateiwiederherstellung” angeboten. Dort gibt es die Möglichkeit ein “Systemimage ” zu erstellen. Zusätzlich sollte auch eine Wiederherstellungs-DVD erstellt werden, diese kann dann auf das Systemimage zugreifen und wieder herstellen.

image

Über “Sicherung erstellen” kommt man zur Auswahl eines Laufwerkes und danach wird das Systemimage erstellt.

image

PC Herunterfahren

In diesem Bereich hat es sicher die größten Verwirrungen gegeben. Die Fülle der Möglichkeiten ist wirklich groß, es gibt den langen Weg durch die Charms bis zur Betätigung des PC-Powerbuttons am Gehäuse.

image

Für mich sind die Neuerungen in Windows8 wirklich Verbesserungen und durch den Einbau einer brauchbaren Dateisicherung bin ich sehr zufrieden mit dem Umstieg.

Appfuse, automatische Erstellung von Java-Webprojekten


Man sollte sich nicht mit unnötigen Tätigkeiten befassen. Eine dieser Tätigkeiten ist das Einrichten von Java-Webprojekten. Für die Erstellung sind eine Unmenge von Projekten miteinander zu verbinden und einige Konfigurationsdateien zu erstellen. Vor allem kann diese Einrichtung wirklich viele Zeit in Anspruch nehmen.

Hier bietet das Projekt Appfuse( und Appfuse-Light) eine automatische Erstellung über Maven an. Der Unterschied besteht beim fehlenden Login in der Lightversion. Die erstellten Anwendungen arbeiten mit Spring und können mit Servern wie Tomcat oder Jetty ausgeführt werden. Die mit Maven erstellten Projekt können auch ohne zusätzliche Einstellungen von NetBeans IDE geöffnet werden. Bei Eclipse ist das Maven-Plugin notwendig.
Von JBoss gibt es für Java EE Anwendungen das Projekt JBoss-Forge. Damit können Anwendungen für den Java Applicationserver erstellt werden.

Gestern habe ich ein neues Projekt mit Maven und Appfuse erstellt, für Details zur Einrichtung sollte man einen Blick auf die QuickStart-Seite werfen. Es können dort auch unterschiedliche WebFrameworks wie Struts2, Spring MVC, Tapestry5, JSF oder nur WebServices gewählt werden.Danach sollte man unbedingt auch

mvn apfuse:full-source

ausführen, damit auch wirklich alle Zusammenhänge im Code sichtbar werden. Nach diesen zwei Schritten kann man das Projekt in Verbindung mit einem MySQL-Server ausführen.

Projektdetails

Der Hauptzweck der Übung war für mich, zu sehen welche Frameworks bei aktuellen Java-Webprojekten eingebunden werden. Folgende Projekte wurden automatisch eingebunden:

Für ein leeres Webprojekt mit nur sehr wenigen Funktionen eigentlich eine Menge. Für mich ist es auf jeden Fall wieder eine gute Quelle, um Neuerungen zu entdecken, die ich dann wieder in bestehende Projekte einfließen lassen kann. Für Neueinsteiger bietet das Projekt Appfuse einen schnellen Einstieg und die Möglichkeit, schnell die Unterschiede zwischen den wählbaren Technologien zu erkennen. Schließlich muss nicht jeder das Rad neu erfinden!

Bildquelle

JPA Transactions in jUnit und Scheduled Tasks mit Spring


In regelmäßigen Abständen versuche ich dieses Problem zu lösen. Meistens habe ich in der Zwischenzeit vergessen, wo ich das Problem das letzte Mal gelöst habe. Die Codestellen vermehren sich zwar, trotzdem wird es Zeit die paar Zeilen Code festzuhalten.

jUnit Spring AbstractTransactionalJUnit4SpringContextTests

Die einfachste Möglichkeit ist die Testklasse von AbstractTransactionalJUnit4SpringContextTests abzuleiten. Leider funktioniert das nur, wenn auch nur genau ein JpaTransactionManager als Spring-Bean existiert. In Systemen mit unterschiedlichen Datenquellen ist damit nichts zu machen.

jUnit Spring mit Annotations

Ist keine Ableitung erwünscht oder existieren mehr als ein TransactionManager, verwende ich meistens diese Lösung. Grundsätzlich ist das genau der Code, der in den zwei Klassen

verwendet wird.

@ContextConfiguration("classpath*:application-context.xml")
@RunWith(SpringJUnit4ClassRunner.class)
@TestExecutionListeners({
    DependencyInjectionTestExecutionListener.class,
    DirtiesContextTestExecutionListener.class,
    TransactionalTestExecutionListener.class
})

@Transactional

@TransactionConfiguration

(transactionManager = "transactionManagerTarget",

defaultRollback = true)

public class TransactionTest{
    @Resource(name="transactionalClass")
    TransactionalClass transactionalClass;
    
   @Transactional
   @Test
    public void testTransaction(){
        ...
    }
}

Mit TransactionManager erstellen

Natürlich kann man mit dem TransactionManager auch direkt eine Transaction öffnen und schließen. Dazu werden auch keine Annotations benötigt.

@Resource(name="transactionManager")
JpaTransactionManager transactionManager;
...
 
DefaultTransactionAttribute transactionAttribute = 
    new DefaultTransactionAttribute (TransactionDefinition.PROPAGATION_REQUIRED);
TransactionStatus status = transactionManager
    .getTransaction(transactionAttribute);

Mit diesen drei Möglichkeiten sollten eigentlich alle Fälle abgedeckt sein. Die beste Quellen dazu war natürlich auf StackOverflow.

Bildquelle