Dekleratif Transaction Yönetimi
- 1. Dünyanın en iyi deklaratif transaction eğitimine hoş geldiniz Harun Çetin
- 3. Transaction Nedir? Veritabanı üzerinde gerçekleştirilen bir grup SQL işleminin tek bir bütün olarak ele alınmasıdır Bir veya daha fazla SQL işlemi tek bir atomik unit olarak ele alınır Transaction yönetimi veri bütünlüğünü sağlar
- 4. Transaction Nedir? Transaction’ın başarılı sonlanmasına commit, başarısız sonlanmasına ve yapılan işlemlerin geri alınmasına rollback denir Her veri erişim teknolojisinin kendine özgü bir transaction başlatma ve bitirme biçimi vardır
- 5. Spring ve Transaction Yönetimi Spring, değişik veri erişim yöntemlerini aynı anda kullanmayı sağlayan ortak bir transaction yönetim API'sine sahiptir Spring'in temel transaction soyutlaması PlatformTransactionManager'dır PlatformTransactionManager sayesinde veri erişimi, TX altyapısından tamamen bağımsız hale gelir
- 6. Spring ve Transaction Yönetimi Veri erişim teknolojisi değiştiği vakit uygulama tarafında bir değişikliğe gerek kalmadan transaction yönetim altyapısı rahatlıkla değiştirilebilir Dekleratif ve programatik TX yönetimi mümkündür Global (dağıtık) ve lokal (tek DB) transactionları destekler
- 8. PlatformTransactionManager Konfigürasyonu Spring Boot kullanılan veri erişim teknolojisine uygun TransactionManager bean tanımını otomatik olarak yapar
- 9. Dekleratif Transaction Yönetimi Uygulama içinde transaction başlatma veya bitirme ile ilgili kod yazılmaz @Transactional anotasyonu ile yapılır @Transactional anotasyonu sınıf veya metot düzeyinde kullanılabilir
- 10. @Transactional Kullanım Örneği @Service @Transactional public class ParentServiceImpl implements ParentService { private ParentRepository parentRepository; private ChildRepository childRepository; ... @Transactional public void delete(Long id) { childRepository.deleteByParentId(id); parentRepository.delete(id); } }
- 11. Dekleratif Transaction Yönetimi Nasıl Çalışır? Servis metot çağrısı geldiği vakit Spring Container tarafından yeni bir transaction başlatılır Metot başarılı sonlandığında transaction commit edilir Metot içerisinden exception fırlatılırsa Exception’ın türüne bakılır Unchecked exception: rollback Checked exception: commit
- 12. Java Exception Hiyerarşisi Bir exception başka bir exception'ı wrap edebilir Asıl hata bilgisi cause exception'dadır JVM spesifik hatalar bu sınıftan extend eder. Bu tür hataların yakalanması uygulamanın görevi değildir Exception veya alt sınıfları ya metot içerisinde yakalanmalı ya da metot imzasına throws clause eklenmelidir RuntimeException ve alt sınıflarının metot içerisinde yakalanması veya metot imzasına throws clause eklenmesi şart değildir
- 15. Transaction Rollback Dekleratif transaction yönetiminde metot başarısız sonlandığında transaction rollback gündeme gelir Metodun başarısız sonlanması, metodun exception fırlatarak sona ermesidir Rollback için exception’ın türüne bakılır Unchecked: rollback Checked: commit
- 16. Checked Exception’larda Rollback Varsayılan durumda checked exception ile sonlanmış transactional bir metot commit edilir Ancak bu davranış değiştirilebilir @Transactional(rollbackFor=Exception.class) public class ParentServiceImpl implements ParentService {... }
- 18. Transaction Propagation Kuralları Servis metodu çağrıldığı vakit, yeni bir transaction’ın başlatılıp başlatılmayacağını, mevcut transaction varsa bunun devam edip etmeyeceğini belirleyen kurallardır REQUIRED REQUIRES_NEW NESTED SUPPORTS NOT_SUPPORTED MANDATORY NEVER
- 20. Transactional metot çağrıldığı vakit aktif transaction yoksa yeni bir transaction başlatılır Aktif transaction varsa aynı transaction içerisinde devam eder Transaction Propagation: REQUIRED
- 21. @Service @Transactional public class ParentServiceImpl implements ParentService { private ParentRepository parentRepository; ... @Override @Transactional(propagation=Propagation.REQUIRED) public void create(Parent parent) { parentRepository.create(parent); } } Transaction Propagation: REQUIRED
- 22. Transactional metot çağrıldığı vakit mutlaka yeni bir transaction başlatılır Eğer aktif bir transaction varsa yeni metot sonlana kadar bekletilir Metot sonlandığı vakit yeni transaction commit/rollback yapılır, daha önce bekletilen transaction kaldığı yerden devam eder Transaction Propagation: REQUIRES_NEW
- 24. @Service public class ParentServiceImpl implements ParentService { private ParentRepository parentRepository; ... @Override @Transactional(propagation=Propagation.REQUIRES_NEW) public void create(Parent parent) { parentRepository.create(parent); } } Transaction Propagation: REQUIRES_NEW
- 25. REQUIRES_NEW propagation kuralına benzer Aktif bir transaction varsa yeni transaction’ı JDBC savepoint oluşturarak bu transaction üzerinden yürütür Metot sonlandığı vakit commit veya rollback, oluşturulan JDBC savepoint’e kadar gerçekleşir Transaction Propagation: NESTED
- 26. Transaction Propagation: NESTED @Service public class ParentServiceImpl implements ParentService { private ParentRepository parentRepository; ... @Override @Transactional(propagation=Propagation.NESTED) public void create(Parent parent) { parentRepository.create(parent); } }
- 27. Diğer TX Propagation Değerleri SUPPORTS: Servis metodu TX varsa TX içinde çalıştırılır TX yoksa, TX'sız çalıştırılır NOT_SUPPORTED: TX varsa suspend edilir, servis metodu mutlaka TX’sız çalıştırılır
- 28. Transaction Propagation: SUPPORTS @Service public class ParentServiceImpl implements ParentService { private ParentRepository parentRepository; ... @Override @Transactional(propagation=Propagation.SUPPORTS,readOnly=true )public List<Parent> find() { return parentRepository.findAll(); } }
- 29. Diğer TX Propagation Değerleri NEVER: Servis metodu çağrıldığında TX varsa exception fırlatılır MANDATORY: Servis metodu çağrıldığında TX yoksa exception fırlatılır
- 31. Read Only Transaction Tanımları ■ JPA/Hibernate kullanırken, salt okuma yapan sorgularda bile aktif bir transaction’a ihtiyaç duyulur ■ Veri erişim işlemlerinde transaction commit sırasında değişikliklerin veritabanı ile senkronize edilmesi söz konusudur ■ Ancak salt okuma yapan sorgular için flush gereksiz ve maliyetli bir iştir.
- 32. Read Only Transaction Tanımları @Service public class ParentServiceImpl implements ParentService { private ParentRepository parentRepository; ... @Override @Transactional(readOnly=true) public List<Parent> finds() { return parentRepository.findAll(); } }
- 33. Timeout ■ Transaction işlemine timeout süresi tanımlayarak işlem bitmediği durumda TransactionTimeOut Exception fırlatılarak rollback olmasını sağlar. ■ Transaction timeout value (in seconds). @Transactional( timeout = 25)
- 34. Zaman ayırdığınız için teşekkürler…
- 35. SOLID PRINCIPLE o Solid bir yazılım geliştiricinin esnek ve gelişmeye açık object oriented programlama yaparken uyması gereken kuralların bir araya getirildiği bir prensiptir. o Dünya standartlarında yazılım geliştirmek için uymamız gereken bu prensipler 5 başlıkta ele alınıyor. Single Responsibility Principle Open/Closed Principle Liskov ‘s Substitution Principle Interface Segregation Principle Dependency Inversion Principle
- 36. Single Responsibility Principle Tek sorumluluk anlamına gelen bu kuralın amacı projede bir değişiklik yapılmak istendiğinde buna bağlı olarak nelerin etkileneceği düşüncesinden kurtulmak ve özgürce isteğimiz geliştirmeyi yapabilmemize olanak sağlamaktır. Her bir method sadece kendisine verilen işi yapar aynı anda birden fazla modeli update etmez, örnek vermek gerekirse bir dizi işi yapan bir fonksiyon yazmaktansa tüm gereksinimleri parçalara ayırıp bağımsız fonksiyonlar ile yapmayı gerektiren bir kuraldır. Böylece zaman içerisinde geliştirme yaparken etkilenecek diğer aşamaları gözden kaçırmanız gibi bir risk oluşmaz.
- 37. Open/Closed Principle Açık kapalı prensibi projemizdeki nesnelerin geliştirmeye açık ama değişime kapalı olmaları anlamına gelmektedir. Oluşturduğunuz nesneler zaman içerisinde ek özellikler kazanabilir genişlemeye açık olurlar bu normal bir yazılım projesinde kaçınılmaz bir durumdur. Ama temel nesne değişime kapalı tutulmalıdır.
- 38. Liskov ‘s Substitution Principle Yerine geçme prensibi kalıtım alarak türeyen sınıfların kalıtım aldıkları nesnenin tüm özellikleri kullanmalı ve sonrasında kendi özelliklerini barındırmasını hedefleyen bir prensiptir eğer nesne kalıtım aldığı objenin tüm özelliklerini kullanmaz ise ortaya gereksiz kod yığınları oluşur ve sonrasında kalıtım alınan objenin diğerlerinden ayrılması için if else bloklarına ihtiyaç olur ve bu durum son derece verimsiz bir yazılıma sebep olur.
- 39. Interface Segregation Principle Arayüz ayırım prensibi, bir arayüze gerektiğinden fazla yetenek eklenmemesi gerektiğini söyler. Nesnelerin ihtiyaç duymadıkları fonksiyonların Interface’lerinden münkün olduğunca ayrıştırılmasıdır.
- 40. Dependency Inversion Principle Bağımlılığın ters çevirilmesi ilkesine göre üst seviye sınıflar, modüller, methodlar vs. alt seviyeli sınıflara bağımlı olmamalıdır. Alt sınıflarda yapılan değişiklikler üst sınıfları etkilememelidir. Yüksek seviyeli sınıflar, düşük seviyeli sınıflara bağlı olmamalı, her ikisi de soyut kavramlara bağlı olmalıdır.