Data Access & Transaction Management

Bu modülde sık geçecek kavramlar

Data access konularında kelimeler birbirine çok yakın görünebilir: entity, repository, persistence context, transaction, propagation… Bu bölümde önce dili sadeleştiriyoruz; sonra derinliğe geçiyoruz.

JPA ne işe yarar?

JPA, veritabanındaki satırlarla Java objeleri arasında köprü kurmamızı sağlar. Ama asıl değer sadece “SQL yazmadan veri çekmek” değildir. Asıl değer; entity yaşam döngüsü, değişiklik takibi, repository modeli ve transaction ile birlikte çalışan tutarlı bir veri erişim katmanı kurmaktır.

JPA hangi problemi çözer?

JDBC ile çalışırken bağlantı açma, SQL yazma, ResultSet okuma, alanları Java objesine map etme, hata yönetimi ve transaction kontrolü çoğu zaman tekrar eden kod üretir. JPA bu tekrarların önemli kısmını soyutlar. Sen entity ve repository modelini kurarsın; framework kayıt bulma, saklama, değişiklik takip etme ve transaction sonunda veritabanına yansıtma süreçlerini yönetir.

MiniBank’ta nerede karşımıza çıkacak?

MiniBank’ta Account, Customer, TransferRecord ve AuditLog gibi entity’ler olacak. Repository’ler bu entity’leri okuyacak/yazacak. Service katmanı ise “para transferi bir bütün olarak başarılı mı başarısız mı?” gibi transaction kararlarını yönetecek.

@Entity
public class Account {
    @Id
    private Long id;

    private String iban;
    private BigDecimal balance;

    // Entity davranışı: bakiye düş, bakiye artır vb.
}

public interface AccountRepository extends JpaRepository<Account, Long> {
    Optional<Account> findByIban(String iban);
}

Persistence Context ve managed entity mantığı

JPA’yı senior seviyede anlamanın kilit noktalarından biri şudur: Repository’den dönen entity sadece sıradan bir Java objesi gibi görünür ama transaction içinde persistence context tarafından takip ediliyor olabilir.

Managed entity ne demek?

Bir entity persistence context içinde managed hale geldiyse, JPA bu objenin değişikliklerini takip eder. Transaction içinde entity üzerinde alan değiştirdiğinde her zaman açıkça save() çağırman gerekmez; transaction sonunda flush sırasında değişiklik veritabanına yansıyabilir. Bu güçlüdür ama davranışın ne zaman gerçekleştiğini bilmezsen şaşırtıcı olabilir.

Lazy loading vs eager loading

Entity ilişkilerinde en sık yapılan hata, “ilişkiyi ne zaman yüklemek istiyorum?” sorusunu bilinçli sormamaktır. Lazy ve eager sadece annotation seçimi değildir; query davranışı, performans ve API response tasarımını etkiler.

MiniBank örneği

Bir hesabın son transferleri her endpoint’te gerekmeyebilir. GET /accounts/{iban} sadece hesap özetini dönebilir. Ama GET /accounts/{iban}/history transfer geçmişini de isteyebilir. Bu iki endpoint aynı veri ihtiyacına sahip değildir; bu yüzden loading stratejisi endpoint ihtiyacına göre düşünülmelidir.

@Entity
public class Account {
    @Id
    private Long id;

    private String iban;

    @OneToMany(mappedBy = "account", fetch = FetchType.LAZY)
    private List<TransferRecord> transfers = new ArrayList<>();
}

N+1 problemi

N+1 problemi, JPA kullanan ekiplerin production’da en sık karşılaştığı performans problemlerinden biridir. Kod küçük görünür, test datasında hızlıdır, ama gerçek veride yüzlerce SQL üretir.

Çok basit anlatım

Diyelim ki 100 hesabı listeledin. İlk query 100 hesabı getirir. Sonra her hesabın transferlerini ayrı ayrı okumaya başlarsan 100 query daha atılır. Toplamda 1 + 100 query oluşur. Buna N+1 diyoruz.

Nasıl fark ederiz?

SQL loglarını açtığında aynı pattern’de tekrar eden select sorguları görürsün. Bu yüzden JPA performansını konuşurken sadece Java koduna bakmak yetmez; üretilen SQL’i de okumak gerekir.

spring:
  jpa:
    show-sql: true
    properties:
      hibernate:
        format_sql: true
logging:
  level:
    org.hibernate.SQL: DEBUG
    org.hibernate.orm.jdbc.bind: TRACE

Çözüm yaklaşımları

public interface JpaAccountRepository extends JpaRepository<JpaAccountEntity, String> {

    @Query("select a from JpaAccountEntity a left join fetch a.histories where a.accountNo = :accountNo")
    Optional<JpaAccountEntity> findByAccountNoWithHistory(String accountNo);

    @EntityGraph(attributePaths = {"customer", "histories"})
    Optional<JpaAccountEntity> findDetailedByAccountNo(String accountNo);
}

@Transactional doğru kullanımı

@Transactional bir “veritabanı işlemi başlat” annotation’ı gibi görünür, ama aslında bir business boundary ifadesidir. “Bu method içindeki iş tek bir bütün olarak başarılı mı olmalı?” sorusunun cevabıdır.

Nereye koymalıyız?

Genel pratik: transaction boundary service katmanında olur. Controller HTTP detayını yönetir, repository veri erişimini yapar, service ise iş akışını ve transaction sınırını belirler. Para transferi gibi bir işte hem gönderen hesabın düşmesi hem alan hesabın artması aynı transaction içinde olmalıdır.

@Service
public class TransferService {

    private final AccountRepository accountRepository;
    private final AuditService auditService;

    public TransferService(AccountRepository accountRepository,
                           AuditService auditService) {
        this.accountRepository = accountRepository;
        this.auditService = auditService;
    }

    @Transactional
    public void transfer(String fromIban, String toIban, BigDecimal amount) {
        Account from = accountRepository.findByIban(fromIban).orElseThrow();
        Account to = accountRepository.findByIban(toIban).orElseThrow();

        from.withdraw(amount);
        to.deposit(amount);

        auditService.recordTransferAttempt(fromIban, toIban, amount);
    }
}

Proxy mantığı burada da geçerli

AOP modülünde gördüğümüz proxy mantığı burada tekrar karşımıza çıkar. @Transactional davranışı Spring proxy’si üzerinden uygulanır. Bu yüzden aynı class içinde this.someTransactionalMethod() çağrısı yaptığında transaction beklendiği gibi çalışmayabilir.

Transaction propagation seviyeleri

Propagation, mevcut bir transaction varken çağrılan başka bir method’un o transaction’a katılıp katılmayacağını belirler. Bu bir enum ezberi değil; iş kuralı kararıdır.

REQUIRED vs REQUIRES_NEW: MiniBank audit kararı

Transfer başarısız olursa audit kaydı da geri alınsın mı? Cevap “evet” ise REQUIRED doğal olabilir. Cevap “transfer rollback olsa bile deneme kaydı kalsın” ise REQUIRES_NEW düşünülebilir. Burada doğru cevap teknik değil, business kararıdır.

@Service
public class AuditService {

    private final AuditLogRepository auditLogRepository;

    public AuditService(AuditLogRepository auditLogRepository) {
        this.auditLogRepository = auditLogRepository;
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void recordTransferAttempt(String fromIban, String toIban, BigDecimal amount) {
        auditLogRepository.save(AuditLog.transferAttempt(fromIban, toIban, amount));
    }
}

Rollback-only ve UnexpectedRollbackException

Bazı durumlarda iç method aynı transaction’a katılır ve hata oluştuğunda transaction rollback-only işaretlenir. Sen exception’ı yakalasan bile transaction artık commit edilemez hale gelmiş olabilir. Bu durumda dış method sonunda commit beklerken rollback gerçekleşebilir.

readOnly, timeout, isolation kısa farkları

Lock stratejileri: aynı hesaba iki paralel transfer

Transaction “bu iş ya tamamen olsun ya hiç olmasın” garantisini verir; ama tek başına “aynı veriyi aynı anda güncelleyen iki işlem birbirini bozmasın” garantisini vermez. Bu ikinci soru eşzamanlılık (concurrency) ve lock konusudur ve MiniBank gibi para hareketi olan sistemlerde göz ardı edilemez.

Senaryo: lost update / race condition

Bir hesabın bakiyesi 100 TL olsun. Aynı anda iki transfer bu hesaptan 50’şer TL çekmeye çalışsın. İkisi de neredeyse aynı anda bakiyeyi 100 olarak okur, kendi hesabını yapar (100 - 50 = 50) ve 50 yazar. Sonuçta hesapta 50 TL kalır; oysa toplam 100 TL çekildiği için 0 olmalıydı. 50 TL boşluktan ortaya çıkmıştır. Buna lost update (kaybolan güncelleme) ya da race condition denir: doğru sonuç, iki işlemin hangi sırayla ve ne kadar iç içe çalıştığına bağlı hale gelmiştir.

Bu problemi @Transactional tek başına çözmez, çünkü her iki işlem de geçerli bir transaction içinde, kendi açısından tutarlı çalışıyor. Eksik olan şey, “bu satırı ben güncellerken başkası araya girmesin” garantisidir. İki temel yaklaşım vardır: optimistic lock ve pessimistic lock.

Optimistic lock: @Version ile çakışmayı yakalama

Optimistic lock, “çakışma nadiren olur, o yüzden baştan kilitlemeyelim; ama olursa fark edelim” yaklaşımıdır. Entity’ye bir @Version alanı eklersin. JPA her güncellemede bu versiyonu kontrol eder: okuduğun versiyon ile yazmaya çalıştığın andaki versiyon farklıysa, demek ki araya başka bir işlem girmiş ve OptimisticLockException fırlatılır. Kimse satırı kilitlemez; çakışma sadece commit anında tespit edilir.

@Entity
@Table(name = "jpa_accounts")
public class JpaAccountEntity {

    @Id
    private String accountNo;

    private BigDecimal balance;

    // Optimistic lock için versiyon alanı.
    // JPA her update'te versiyonu kontrol eder ve bir artırır.
    @Version
    private long version;

    // ... mevcut alanlar ve metotlar
}

Çakışma yakalandığında genelde işlemi baştan denemek (retry) mantıklıdır: hesabın güncel halini tekrar oku, işlemi tekrar uygula, tekrar commit etmeyi dene. Çünkü çakışma genelde geçicidir; ikinci denemede karşı işlem çoktan bitmiş olur.

public void transferWithRetry(String fromAccountNo, String toAccountNo, BigDecimal amount) {
    int attempts = 0;
    while (true) {
        try {
            transfer(fromAccountNo, toAccountNo, amount); // @Transactional
            return;
        } catch (OptimisticLockException ex) {
            if (++attempts >= 3) {
                throw ex; // çakışma ısrarcı: pes et ve yukarı bildir
            }
            // kısa bekle ve tekrar dene
        }
    }
}

Pessimistic lock: satırı baştan kilitlemek

Pessimistic lock, “çakışma olacak, o yüzden satırı en baştan kilitleyelim” yaklaşımıdır. İlgili satırı okurken veritabanı düzeyinde kilitlersin; bu da arka planda SELECT ... FOR UPDATE sorgusuna dönüşür. İkinci işlem aynı satıra dokunmak istediğinde, ilk işlem commit edip kilidi bırakana kadar bekler. Böylece iki işlem gerçekten sıraya girer, lost update imkansız hale gelir.

public interface JpaAccountRepository extends JpaRepository<JpaAccountEntity, String> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select a from JpaAccountEntity a where a.accountNo = :accountNo")
    Optional<JpaAccountEntity> findByAccountNoForUpdate(@Param("accountNo") String accountNo);
}

Bu metot bir @Transactional service içinden çağrıldığında, kilit transaction commit olana kadar tutulur. Transfer akışında gönderen hesabı bu metotla okursan, aynı hesaptan eş zamanlı başka bir transfer denemesi senin işlemin bitmesini bekler.

Hangisi ne zaman?

Bu modülden akılda kalması gerekenler