Java / Spring Boot

Sie steuert das Transaktionsmanagement in Spring. Methoden oder Klassen mit @Transactional laufen in einer Datenbanktransaktion.

1. Startet automatisch eine Transaktion beim Methodenaufruf

2. Führt Commit nach erfolgreichem Abschluss aus

3. Führt Rollback bei Ausnahmen durch (standardmäßig bei RuntimeException und Error)

Der Isolationsgrad bestimmt, wie stark parallele Transaktionen voneinander abgeschottet sind, um Probleme wie Dirty Reads, Non-Repeatable Reads oder Phantom Reads zu vermeiden.

🔹 Bedeutung:

• Signalisiert, dass keine Schreiboperationen stattfinden

• Optimiert Performance:

  • Hibernate kann das Dirty-Checking deaktivieren

  • DB kann evtl. leichtere Locks setzen oder Caching nutzen

• Kann z. B. bei Reporting, Suche, Abfragen verwendet werden

🔹 Wichtig:

• Nur eine Lese-Absicht wird ausgedrückt – es verhindert nicht aktiv das Schreiben

Ohne @Transactional(readOnly = true):

• Es wird gar keine Transaktion gestartet → Lazy-Loading kann fehlschlagen.

• Performance kann schlechter sein.

• Keine Absicherung gegen versehentliches Schreiben (z. B. durch Entity-Manipulation ohne Absicht).

🔁 Zusammenfassung für deine Karteikarte:

Warum @Transactional(readOnly = true) verwenden? → Für konsistente Leseoperationen mit Transaktion, bessere Performance, und klare Trennung von Lese-/Schreiblogik.

Sie markiert den Spring ApplicationContext als "verschmutzt" (dirty), sodass er nach dem Test neu erstellt wird. Das verhindert Seiteneffekte zwischen Tests, ist aber langsamer.

Nach jedem Testmethodenlauf wird der ApplicationContext verworfen und für den nächsten Test frisch aufgebaut.

Wenn Tests starke Nebeneffekte auf den ApplicationContext haben (z. B. Datenbankzustände, Bean-Modifikationen), die sich nicht leicht zurücksetzen lassen.

1. Sehr langsame Testausführung, da der gesamte ApplicationContext jedes Mal neu aufgebaut wird.

2. Sollte nur verwendet werden, wenn keine bessere Isolation möglich ist (z. B. durch Transaktionen oder Testdaten-Reset).

Es wird der Standart Wwert genommen.

Standartwert ist AFTER_CLASS.

Nein.

spring-boot-starter-parent ist kein Spring Boot selbst, sondern ein Maven-Parent-POM, das Standardkonfigurationen und Dependency-Management für Spring Boot-Projekte bereitstellt.

Ja,

aber dann muss man die Versionen und Plugin-Konfigurationen selbst verwalten.

Mit spring-boot-dependencies (als dependencyManagement) kann man ein eigenes Parent-POM nutzen.

1. spring-boot-starter-parent = Parent-POM für Maven-Projekte (Konfiguration + Dependency-Management).

2. Spring Boot Starter (z. B. spring-boot-starter-web) = Sammlungen von Bibliotheken, die typische Funktionalitäten bereitstellen.

Mit spring-boot-starter-parent genau dort.

Ohne, dann bei spring-boot-dependencies.

Ein Objekt, das von Spring verwaltet wird (Lifecycle, Abhängigkeiten, Konfiguration). Beans sind Teil des ApplicationContext.

1. Mit @Component, @Service, @Repository, @Controller (automatische Erkennung durch Component Scan).

2. Oder durch @Bean in einer @Configuration-Klasse.

1. @Component: Automatische Bean-Erkennung durch Classpath-Scanning.

2. @Bean: Explizite Bean-Definition in einer @Configuration-Klasse.

Singleton – es gibt nur eine Instanz pro ApplicationContext.

1. singleton (Standard)

2. prototype (neue Instanz bei jedem Zugriff)

3. web-bezogen: request, session, application, websocket

1. Über Konstruktor-Injektion (empfohlen)

2. Über Feld-Injektion (@Autowired)

3. Über Setter-Injektion

1. Mit @Qualifier("beanName")

2. Mit @Primary (legt die Standard-Bean fest)

Bindet Werte aus application.properties oder application.yml an ein Bean-Objekt (stark typisiert, mit Getter/Setter).

1. Beans werden nicht sofort beim Start des ApplicationContext erstellt, sondern erst bei der ersten Verwendung (Lazy Initialization).

2. Spart Ressourcen beim Start, ist aber langsamer beim ersten Zugriff.

3. Kann auf Klassen (@Component, @Service, …) oder einzelne Bean-Definitionen (@Bean) angewendet werden.

Wenn eine Bean erst bei Bedarf und nicht direkt beim ApplicationContext-Start erstellt werden soll (z. B. für Performance oder wenn Abhängigkeiten optional sind).

1. Mit @PostConstruct und @PreDestroy

2. Über Interfaces wie InitializingBean, DisposableBean

3. Mit @Bean(initMethod = "...", destroyMethod = "...")

Sie markiert die Klasse als Konfigurationsklasse, die Beans mit @Bean-Methoden definiert. Sie ersetzt XML-Konfiguration.

Ja, @Configuration ist selbst mit @Component annotiert. Sie wird also auch durch Component Scanning gefunden.