Veritabanı READ COMMITTED isolation seviyesinde çalışıyor; metotta ayrıca bir isolation belirtilmemiş. Gün içinde sürekli yeni sipariş gelirken çalışan günlük rapor bazen tutarsız çıkıyor: listedeki siparişlerin tutarları toplandığında total'dan büyük bir sayı çıkıyor.

@Service
public class SalesReportService {
    private final OrderRepository orderRepository;

    public SalesReportService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    @Transactional(readOnly = true)
    public DailyReport dailyReport(LocalDate day) {
        BigDecimal total = orderRepository.sumAmountByDay(day); // SELECT SUM(amount) ...
        List<Order> orders = orderRepository.findByDay(day);    // SELECT ... WHERE day = ?
        return new DailyReport(total, orders);
    }
}

Tutarsızlığın sebebi ve uygun düzeltme hangisi?

22:T1820,

Destek ekibi, başarısız olanlar dahil her sipariş denemesinin audit_log tablosunda görünmesini istiyor. Mevcut kod şöyle:

@Service
public class OrderService {
    private final OrderRepository orderRepository;
    private final StockService stockService;
    private final AuditLogRepository auditLogRepository;

    public OrderService(OrderRepository orderRepository, StockService stockService,
                        AuditLogRepository auditLogRepository) {
        this.orderRepository = orderRepository;
        this.stockService = stockService;
        this.auditLogRepository = auditLogRepository;
    }

    @Transactional
    public Order placeOrder(OrderRequest request) {
        auditLogRepository.save(AuditLog.attempt(request));
        // stok yetmezse OutOfStockException (RuntimeException) fırlatır
        stockService.decrease(request.productId(), request.quantity());
        return orderRepository.save(Order.from(request));
    }
}

Stok yetmediğinde audit kaydı da tabloda yok. Sebebi ne? Nasıl düzeltirsin? Çözümünün bedeli ne, başka hangi seçenekler var ve hangisini neden seçersin?

23:T644,

Audit satırı placeOrder()'ın transaction'ında yazılıyor: save() varsayılan REQUIRED ile mevcut transaction'a katılır. OutOfStockException metottan çıkınca transaction rollback olur, audit satırı da geri alınır.

Çözüm 1: Audit yazımını ayrı bir AuditService bean'ine taşıyıp metodu @Transactional(propagation = Propagation.REQUIRES_NEW) yapmak. Dış transaction askıya alınır, audit kendi transaction'ında commit olur; sipariş geri alınsa da kayıt kalır. Metot ayrı bean'de olmalı; aynı sınıftan çağrılırsa proxy atlanır.

Bedeli: dış transaction connection'ını tutarken iç transaction ikinci bir connection alır. Yoğun trafikte pool tükenebilir, thread'ler ikinci connection'ı beklerken kilitlenebilir; pool boyutu buna göre ayarlanmalı. Audit yazımı hata verirse exception siparişe yayılır; siparişi bozmaması için yakalanmalı.

Çözüm 2: Audit'i sipariş transaction'ının dışında yazmak. Transaction'sız bir OrderFacade, placeOrder()'ı try/catch ile çağırır, sonucu (başarılı ya da başarısızlık sebebi) AuditService ile kendi transaction'ında kaydeder. Aynı anda iki connection tutulmaz; bedeli bir katman daha.

Seçimim Çözüm 2: destek ekibi için denemenin sonucu da değerli ve connection bedeli yok. Kod yapısını değiştirmek zorsa ve pool yeterliyse REQUIRES_NEW da kabul edilebilir.

24:T1433,

Transaction ve isolation ayarları varsayılan. Stok düşürme kodu şöyle:

@Service
public class StockService {
    private final ProductRepository productRepository;

    public StockService(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    @Transactional
    public void reserve(Long productId, int quantity) {
        Product product = productRepository.findById(productId).orElseThrow();
        if (product.getStock() < quantity) {
            throw new OutOfStockException(productId);
        }
        product.setStock(product.getStock() - quantity);
    }
}

Stokta 1 adet kalan bir üründen iki kullanıcı neredeyse aynı anda 1'er adet aldı. İki istek de başarılı oldu, stok 0 görünüyor ama 2 ürün satıldı. Sebebi ne? Nasıl düzeltirsin? Aklına gelen seçeneklerden hangisini neden seçersin?

25:T539,

İki istek stoğu aynı anda 1 olarak okur, ikisi de kontrolü geçer ve ikisi de 0 yazar; sonra yazan öncekini ezer (lost update). @Transactional bunu tek başına engellemez.

Seçenekler:

Optimistic locking: Product'a @Version alanı. Hibernate UPDATE'e versiyon koşulu ekler; ikinci commit satırı güncelleyemez ve ObjectOptimisticLockingFailureException alır. Kilit tutmaz, ama çakışmada işlem yeniden denenmeli ya da kullanıcıya bildirilmeli.
Pessimistic lock: ürünü @Lock(LockModeType.PESSIMISTIC_WRITE) ile okumak (SELECT ... FOR UPDATE). İkinci istek bekler, sonra güncel stoğu görür; retry gerekmez. Bedeli: istekler sıraya girer, kilit transaction boyunca tutulur, deadlock riski var.
Koşullu tek UPDATE: stock = stock - :q WHERE id = :id AND stock >= :q; 0 satır etkilendiyse stok yok. Basit ve sağlam, ama iş kuralı SQL'e taşınır.
Isolation yükseltmek: davranışı veritabanına göre değiştiği için ilk tercihim değil.

Seçimim: normal günde çakışma seyrek olduğu için @Version ve sınırlı retry. Kampanya gibi aynı ürüne yoğun istek beklenen durumda pessimistic lock veya koşullu UPDATE.

7:["$","$L11",null,{"topic":{"id":"jpa-transaction","contentKey":"jpa-transaction.orm-basics.identity-generation@2|jpa-transaction.orm-basics.jpa-vs-hibernate@1|jpa-transaction.orm-basics.missing-id@1|jpa-transaction.entity-mapping.many-to-one@1|jpa-transaction.entity-mapping.owning-side@1|jpa-transaction.transactions.checked-exception-rollback@1|jpa-transaction.transactions.read-only@2|jpa-transaction.transactions.service-boundary@1|jpa-transaction.persistence-context.dirty-checking@1|jpa-transaction.persistence-context.first-level-cache@1|jpa-transaction.persistence-context.merge-overwrites-fields@2|jpa-transaction.fetching.lazy-initialization@3|jpa-transaction.fetching.n-plus-one@3|jpa-transaction.entity-mapping.cascade-on-many-to-one@1|jpa-transaction.transactions.inner-exception-caught@2|jpa-transaction.transactions.report-consistency@3|jpa-transaction.transactions.audit-log-on-failure@1|jpa-transaction.transactions.concurrent-stock-update@2","title":"JPA & Transaction","subtopics":[{"id":"orm-basics","title":"ORM, JPA ve Hibernate temelleri; entity ve id"},{"id":"entity-mapping","title":"İlişkiler, owning side, cascade ve orphanRemoval"},{"id":"fetching","title":"Lazy/eager, N+1, LazyInitializationException"},{"id":"persistence-context","title":"Entity durumları, persistence context, dirty checking"},{"id":"transactions","title":"@Transactional kullanımı, rollback, propagation, isolation"}],"levels":{"1":"ORM ve JPA'nın ne olduğunu, entity/id ve temel anotasyonları tanır.","2":"İlişkileri ve @Transactional'ı doğru kullanır; varsayılan fetch ve rollback davranışını, propagation'ın temel davranışını (mevcut transaction'a katılma / ayrı transaction açma) bilir.","3":"Persistence context'in ve fetch stratejilerinin nasıl çalıştığını açıklar; N+1 ve LazyInitializationException'ı teşhis eder.","4":"Propagation, isolation ve cascade seçimlerinin sonuçlarını tartar; gerçek senaryoda gerekçeli seçim yapar (güçlü junior)."},"questions":[{"id":"jpa-transaction.orm-basics.identity-generation","level":1,"subtopic":"orm-basics","promptHtml":"

Bir entity'de id alanı @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; olarak tanımlanmış. Bu tanım ne anlama gelir?

\n","explanationHtml":"

JPA'daki başlıca stratejiler: IDENTITY (veritabanının identity/auto-increment kolonu), SEQUENCE (veritabanı sequence'i), UUID ve sağlayıcının seçtiği AUTO. GenerationType.UUID, Jakarta Persistence 3.1 ile eklendi. IDENTITY'de id ancak satır eklendikten sonra bilinir; bu yüzden Hibernate INSERT'i hemen çalıştırır ve bu entity için toplu (JDBC batch) insert yapamaz. Hibernate, veritabanı destekliyorsa SEQUENCE kullanılmasını önerir.

\n","resources":[{"id":"jakarta-persistence-spec","title":"Jakarta Persistence 3.1 Specification","url":"https://jakarta.ee/specifications/persistence/3.1/","kind":"docs","lang":"en","levels":[1,2,3,4]},{"id":"hibernate-user-guide","title":"Hibernate ORM User Guide","url":"https://docs.jboss.org/hibernate/orm/6.6/userguide/html_single/Hibernate_User_Guide.html","kind":"docs","lang":"en","levels":[2,3,4]}],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"Id'yi veritabanı üretir: satır eklenirken identity (auto-increment) kolonu bir sonraki değeri verir.","correct":true,"misconceptionHtml":"$undefined"},{"id":"b","html":"Id'yi Hibernate uygulamanın içinde üretir: bellekte bir sayaç tutar ve her yeni nesnede onu bir artırır.","correct":false,"misconceptionHtml":"Değerin uygulamada üretildiğini sanıyor. IDENTITY'de değeri veritabanı üretir; Hibernate bu değeri INSERT'ten sonra veritabanından alır. Bellekte tutulan bir sayaç, uygulamanın birden çok instance'ı çalıştığında çakışan id'ler üretirdi."},{"id":"c","html":"Id değerini kaydetmeden önce sen vermelisin; IDENTITY yalnız bu alanın birincil anahtar olduğunu belirtir.","correct":false,"misconceptionHtml":"@GeneratedValue'yu @Id ile karıştırıyor. Alanın birincil anahtar olduğunu @Id söyler; @GeneratedValue değerin otomatik üretileceğini belirtir, bu yüzden yeni kayıtta id'yi elle vermezsin."},{"id":"d","html":"Her yeni kayda benzersiz bir UUID atanır; böylece id'ler farklı veritabanlarında bile çakışmaz.","correct":false,"misconceptionHtml":"IDENTITY'yi GenerationType.UUID ile karıştırıyor. UUID stratejisi benzersiz bir UUID üretir; IDENTITY ise veritabanının kendi artan sayısal kolonunu kullanır."}]},{"id":"jpa-transaction.orm-basics.jpa-vs-hibernate","level":1,"subtopic":"orm-basics","promptHtml":"

JPA (Jakarta Persistence) ile Hibernate arasındaki ilişki nedir?

\n","explanationHtml":"

ORM, Java nesneleri ile ilişkisel tablolar arasındaki eşlemeyi senin yerine yapar. JPA bu işin standardıdır: @Entity, @Id, EntityManager gibi arayüz ve anotasyonları tanımlar ama kendi başına çalışmaz. Hibernate bu standardı uygulayan sağlayıcıdır (provider) ve kendine özgü ek özellikler de sunar. Kodu mümkün olduğunca JPA API'sine yazmak, sağlayıcıya bağımlılığı azaltır. Spring Boot 3'te paket adı jakarta.persistence'tır.

\n","resources":["$7:props:topic:questions:0:resources:0","$7:props:topic:questions:0:resources:1"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"İkisi aynı kütüphanenin farklı adlarıdır; Hibernate eski adıdır, JPA ise Jakarta'ya geçişten sonraki yeni adıdır.","correct":false,"misconceptionHtml":"JPA ile Hibernate'i aynı şey sanıyor. JPA bir standarttır; Hibernate onu uygulayan ürünlerden biridir (EclipseLink de bir başkasıdır). Jakarta'ya geçişte değişen, standardın adı ve paketidir (javax.persistence → jakarta.persistence)."},{"id":"b","html":"JPA, nesneleri tablolara eşlemek için standart bir API tanımlar; Hibernate bu standardı uygulayan bir ORM framework'üdür.","correct":true,"misconceptionHtml":"$undefined"},{"id":"c","html":"Hibernate, Spring'in JPA modülüdür; Spring kullanmayan bir projede Hibernate ile çalışmak mümkün değildir.","correct":false,"misconceptionHtml":"Hibernate'i Spring'in bir parçası sanıyor. Hibernate, Spring'den bağımsız bir projedir ve tek başına kullanılabilir. Spring Boot'ta spring-boot-starter-data-jpa JPA sağlayıcısı olarak Hibernate'i getirir; Spring Data JPA ise JPA'nın üstüne repository katmanı ekler."},{"id":"d","html":"JPA, veritabanına SQL gönderen düşük seviyeli sürücü API'sidir; Hibernate onun üstünde çalışan bir sorgu aracıdır.","correct":false,"misconceptionHtml":"JPA'yı JDBC ile karıştırıyor. SQL'i veritabanına gönderen düşük seviyeli API JDBC'dir. JPA nesne-ilişkisel eşleme (ORM) için bir standarttır; Hibernate gibi sağlayıcılar altta JDBC kullanır."}]},{"id":"jpa-transaction.orm-basics.missing-id","level":1,"subtopic":"orm-basics","promptHtml":"$12","explanationHtml":"

Her entity'nin bir birincil anahtarı olmak zorundadır ve JPA bunu alan adından tahmin etmez; anahtar @Id (veya bileşik anahtarlarda @EmbeddedId/@IdClass) ile belirtilir. Id genellikle @GeneratedValue ile birlikte kullanılır. Bir entity için zorunlu olanlar kısaca: @Entity, bir @Id ve public ya da protected argümansız constructor. @Column, @Table ve Serializable ise ihtiyaca göre eklenir.

\n","resources":["$7:props:topic:questions:0:resources:0"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"Alanlar @Column ile işaretlenmemiş; JPA yalnızca @Column taşıyan alanları tablodaki kolonlara eşler.","correct":false,"misconceptionHtml":"Alanların yalnız @Column ile kalıcı hâle geldiğini sanıyor. @Transient ile işaretlenmeyen alanlar varsayılan olarak kalıcıdır; @Column yalnız kolon adı, uzunluk, null kabul etme gibi ayarları değiştirmek için gerekir."},{"id":"b","html":"Sınıf Serializable arayüzünü uygulamıyor; JPA her entity'nin serileştirilebilir olmasını zorunlu tutar.","correct":false,"misconceptionHtml":"Serializable'ı zorunlu sanıyor. Spesifikasyon bunu yalnız entity başka bir sürece değer olarak (detached nesne olarak, remote) gönderilecekse ister; sıradan bir entity için zorunlu değildir."},{"id":"c","html":"Sınıfta @Table yok; bu anotasyon olmadan JPA entity'nin hangi tabloya yazılacağını bilemez.","correct":false,"misconceptionHtml":"Tablo adının mutlaka belirtilmesi gerektiğini sanıyor. @Table yoksa tablo adı entity adından (varsayılan olarak sınıf adı) türetilir; @Table yalnız farklı bir ad veya şema istendiğinde gerekir."},{"id":"d","html":"Birincil anahtar tanımlanmamış; alanın adının id olması yetmez, alan @Id ile işaretlenmelidir.","correct":true,"misconceptionHtml":"$undefined"}]},{"id":"jpa-transaction.entity-mapping.many-to-one","level":1,"subtopic":"entity-mapping","promptHtml":"

Bir müşterinin (Customer) birden çok siparişi olabilir; her sipariş (Order) ise tek bir müşteriye aittir. Order sınıfındaki private Customer customer; alanı için doğru eşleme hangisidir?

\n","explanationHtml":"

Anotasyon adı, alanın bulunduğu sınıftan hedefe doğru okunur: 'birçok Order → bir Customer', yani @ManyToOne. İlişkisel veritabanında bu, 'çok' tarafın tablosundaki bir foreign key kolonuyla tutulur. Varsayılan kolon adı alan adı + _ + hedefin birincil anahtar kolonudur (customer_id); istersen @JoinColumn ile değiştirirsin. Müşteriden siparişlere de gitmek istersen Customer sınıfına @OneToMany(mappedBy = "customer") eklenir.

\n","resources":["$7:props:topic:questions:0:resources:0"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"@OneToMany, çünkü ilişkinin bir ucunda tek müşteri, diğer ucunda o müşterinin birden çok siparişi var.","correct":false,"misconceptionHtml":"İlişkiyi karşı taraftan okuyor. Anotasyon, alanın bulunduğu sınıftan bakılarak seçilir: birçok sipariş tek bir müşteriye bağlanır, yani Order tarafında @ManyToOne. @OneToMany istenirse Customer sınıfındaki sipariş koleksiyonuna konur."},{"id":"b","html":"@OneToOne, çünkü bir siparişin yalnızca tek bir müşterisi olabilir ve bu müşteri sonradan değişmez.","correct":false,"misconceptionHtml":"İlişkiye yalnız bir yönden bakıyor. Her siparişin tek müşterisi olması yetmez; aynı müşteri birden çok siparişte yer alabildiği için ilişki one-to-one değil many-to-one'dır."},{"id":"c","html":"@ManyToOne; sipariş tablosunda müşteriyi gösteren bir foreign key (customer_id) tutulur.","correct":true,"misconceptionHtml":"$undefined"},{"id":"d","html":"@ManyToMany, çünkü sistemde hem birçok müşteri hem de birçok sipariş kaydı aynı anda bulunur.","correct":false,"misconceptionHtml":"Tablodaki kayıt sayısını ilişki türüyle karıştırıyor. İlişki türü toplam satır sayısına göre değil, bir siparişin kaç müşteriye ve bir müşterinin kaç siparişe bağlanabildiğine göre belirlenir."}]},{"id":"jpa-transaction.entity-mapping.owning-side","level":2,"subtopic":"entity-mapping","promptHtml":"$13","explanationHtml":"

Çift yönlü bir ilişkide veritabanında tek bir foreign key vardır ve onu yöneten taraf owning side'dır. One-to-many / many-to-one ilişkide owning side her zaman 'çok' taraf, yani @ManyToOne alanıdır; mappedBy ise karşı tarafa (inverse side) yazılır ve 'bu ilişkinin sahibi karşıdaki alan' der. Bu yüzden employee.setDepartment(department) çağrılmalıdır. Bellekteki nesnelerin de tutarlı kalması için iki tarafı birlikte güncelleyen bir yardımcı metot (örn. Department.addEmployee(e): listeye ekler ve e.setDepartment(this) çağırır) yaygın bir çözümdür.

\n","resources":["$7:props:topic:questions:0:resources:0","$7:props:topic:questions:0:resources:1"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"Çalışan kaydedilir ama department_id NULL kalır; ilişkiyi owning side olan Employee.department belirler.","correct":true,"misconceptionHtml":"$undefined"},{"id":"b","html":"Çalışan department_id dolu olarak kaydedilir; Hibernate ilişkiyi departmanın employees listesinden anlar.","correct":false,"misconceptionHtml":"İlişkiyi mappedBy olan (inverse) tarafın belirlediğini sanıyor. Inverse taraftaki koleksiyona yapılan değişiklikler foreign key'e yansımaz; veritabanına yazılan, owning side'daki employee.getDepartment() değeridir."},{"id":"c","html":"Metot exception ile biter; Hibernate ilişkinin iki tarafının tutarsız olduğunu fark eder ve kaydı reddeder.","correct":false,"misconceptionHtml":"JPA'nın iki tarafın tutarlılığını denetlediğini sanıyor. Spesifikasyona göre iki tarafı tutarlı tutmak geliştiricinin sorumluluğudur; Hibernate bunu kontrol etmez, ilişkiyi sessizce owning side'a göre yazar."},{"id":"d","html":"Çalışan kaydedilir ve ilişki, iki tabloyu bağlayan ayrı bir join table'a eklenen bir satırla kurulur.","correct":false,"misconceptionHtml":"@OneToMany'nin her zaman join table kullandığını sanıyor. Join table, mappedBy olmayan tek yönlü @OneToMany için varsayılandır. Burada mappedBy olduğu için ilişki yalnız çalışan tablosundaki foreign key kolonuyla tutulur."}]},{"id":"jpa-transaction.transactions.checked-exception-rollback","level":2,"subtopic":"transactions","promptHtml":"$14","explanationHtml":"

Spring'in varsayılan kuralı: unchecked exception (RuntimeException ve alt sınıfları) ve Error rollback'e, checked exception commit'e yol açar. Burada ödeme alınmadığı hâlde rezervasyon kalıcı olur. Düzeltme için @Transactional(rollbackFor = PaymentFailedException.class) yazılabilir ya da exception RuntimeException'dan türetilebilir. Spring 6.2'den beri bu varsayılan, @EnableTransactionManagement(rollbackOn = RollbackOn.ALL_EXCEPTIONS) ile uygulama genelinde de değiştirilebilir.

\n","resources":[{"id":"spring-docs-transactions","title":"Spring Framework Reference: Transaction Management","url":"https://docs.spring.io/spring-framework/reference/data-access/transaction.html","kind":"docs","lang":"en","levels":[2,3,4]}],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"Geri alınır; @Transactional metottan dışarı çıkan her exception'da, türüne bakmadan transaction'ı rollback eder.","correct":false,"misconceptionHtml":"Her exception'da rollback yapıldığını sanıyor. Varsayılan kural yalnız RuntimeException ve Error için rollback'tir; checked exception'larda transaction commit edilir."},{"id":"b","html":"Geri alınır ve exception Spring tarafından yakalanır; bu yüzden reserve()'u çağıran kod hatayı hiç görmez.","correct":false,"misconceptionHtml":"Spring'in exception'ı yuttuğunu sanıyor. Transaction altyapısı commit ya da rollback kararını verdikten sonra exception'ı olduğu gibi çağırana iletir."},{"id":"c","html":"Ne commit ne rollback yapılır; transaction açık kalır ve bağlantı zaman aşımına uğrayana kadar bekler.","correct":false,"misconceptionHtml":"Checked exception'da transaction'ın askıda kaldığını sanıyor. Metot hangi exception ile biterse bitsin Spring transaction'ı sonlandırır; rollback kuralına göre ya commit ya rollback yapar."},{"id":"d","html":"Commit edilir; varsayılan olarak yalnız unchecked hatalar (RuntimeException, Error) rollback'e yol açar.","correct":true,"misconceptionHtml":"$undefined"}]},{"id":"jpa-transaction.transactions.read-only","level":2,"subtopic":"transactions","promptHtml":"$15","explanationHtml":"

readOnly = true, altyapıya 'bu transaction veri değiştirmeyecek' ipucunu verir. Hibernate ile kullanıldığında flush modu MANUAL olur ve değişiklik kontrolü atlanır; Spring ayrıca JDBC bağlantısını read-only işaretler, bazı veritabanları da buna göre optimizasyon yapar. Spring'e göre bu yalnız bir ipucudur: yazma girişimini her zaman engellemez. Bazı veritabanları (ör. PostgreSQL) read-only transaction'da yazmayı reddeder, ama bu bir güvenlik önlemi sayılmaz; erişim kontrolü veritabanı kullanıcı yetkileriyle yapılır. Sorgu yapan servis metotlarında kullanılması yaygın bir iyi uygulamadır. Spring Data JPA'nın hazır okuma metotları (findById, findAll vb.) zaten readOnly = true ile çalışır.

\n","resources":["$7:props:topic:questions:5:resources:0",{"id":"spring-data-jpa-transactions","title":"Spring Data JPA Reference: Transactionality","url":"https://docs.spring.io/spring-data/jpa/reference/jpa/transactions.html","kind":"docs","lang":"en","levels":[2,3]}],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"Metot hiç transaction açılmadan çalışır; readOnly, 'bu metot için transaction başlatma' anlamına gelir.","correct":false,"misconceptionHtml":"readOnly'nin transaction'ı kapattığını sanıyor. Transaction yine açılır (varsayılan propagation REQUIRED); yalnızca salt okunur olarak işaretlenir."},{"id":"b","html":"Okunan satırlar transaction bitene kadar kilitlenir; böylece başka işlemler bu verileri o sırada değiştiremez.","correct":false,"misconceptionHtml":"readOnly'yi kilitleme veya isolation ile karıştırıyor. readOnly başka transaction'ların yazmasını engellemez; kilitler ve hangi değişikliklerin görüleceği isolation seviyesi ve lock ayarlarıyla belirlenir."},{"id":"c","html":"Transaction'ın veri değiştirmeyeceğini bildirir; Hibernate gibi altyapılar buna göre optimize eder (ör. flush'ı atlar).","correct":true,"misconceptionHtml":"$undefined"},{"id":"d","html":"Metodun sonucunu önbelleğe alır; aynı parametreyle yapılan ikinci çağrıda sorgular veritabanına gönderilmez, sonuç bellekten döner.","correct":false,"misconceptionHtml":"readOnly'yi önbellekle (@Cacheable veya sorgu önbelleği) karıştırıyor. readOnly sonuç saklamaz; metot her çağrıldığında sorgular yeniden çalışır. Sonuçları önbelleğe almak ayrı bir mekanizmadır ve ayrıca yapılandırılır."}]},{"id":"jpa-transaction.transactions.service-boundary","level":2,"subtopic":"transactions","promptHtml":"$16","explanationHtml":"

Transaction sınırı iş biriminin (burada 'transfer') sınırı olmalıdır; bu da genellikle birden çok repository çağrısını yöneten servis metodudur. Spring Data JPA'da CrudRepository metotları varsayılan olarak kendi transaction'larında çalışır (okuma metotları readOnly = true ile). Servis metodu @Transactional olunca repository çağrıları bu transaction'a katılır ve IllegalStateException gibi bir RuntimeException iki değişikliği de geri aldırır.

\n","resources":["$7:props:topic:questions:5:resources:0"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"Hiçbir değişiklik kaydedilmez, çünkü @Transactional olmadan repository'ler veritabanına yazamaz; anotasyon eklenince kod çalışır.","correct":false,"misconceptionHtml":"Repository'lerin yazmak için dışarıdan bir transaction'a ihtiyaç duyduğunu sanıyor. Spring Data JPA'da save() gibi metotlar zaten kendi transaction'ında çalışır; bu yüzden ilk save() tek başına commit edilir."},{"id":"b","html":"from'daki düşüş kalıcı olur, çünkü ilk save() kendi transaction'ında commit edildi; transfer() @Transactional yapılmalı.","correct":true,"misconceptionHtml":"$undefined"},{"id":"c","html":"İki değişiklik de geri alınır, çünkü exception aynı metodun içinde fırladı; bu yüzden kod bu hâliyle doğru çalışır.","correct":false,"misconceptionHtml":"Bir metodun kendiliğinden bir transaction olduğunu sanıyor. Transaction'ı metot değil, @Transactional (veya programatik transaction yönetimi) başlatır; anotasyon yoksa her repository çağrısı ayrı commit edilir."},{"id":"d","html":"from'daki düşüş kalıcı olur; AccountRepository arayüzündeki metotların her birine ayrıca @Transactional eklenmelidir.","correct":false,"misconceptionHtml":"Transaction sınırını yanlış katmanda arıyor. Repository metotları zaten tek tek transactional'dır; her birine anotasyon koymak onları tek transaction'da birleştirmez. Birleştiren, iki çağrıyı da kapsayan servis metodundaki @Transactional'dır."}]},{"id":"jpa-transaction.persistence-context.dirty-checking","level":3,"subtopic":"persistence-context","promptHtml":"$17","explanationHtml":"

Bir transaction içinde findById veya sorguyla yüklenen entity'ler persistence context'te managed\ndurumdadır. Hibernate her birinin yüklendiği andaki hâlini saklar ve flush sırasında (varsayılan\nolarak commit'ten önce) mevcut değerlerle karşılaştırır; fark varsa UPDATE üretir. Buna dirty\nchecking denir ve managed bir entity'yi güncellemek için save() çağırmak gerekmez. Düzeltme:\nönizleme için managed entity'yi değiştirmemek, hesabı yerel bir değişkende yapmak\n(BigDecimal discounted = product.getPrice().multiply(...)). Metodu @Transactional(readOnly = true)\nyapmak ek bir güvencedir: Spring, Hibernate ile read-only transaction'da session'ın flush modunu\nMANUAL yapar ve değişiklik yazılmaz. Ama asıl düzeltme, kaydedilmeyecek bir hesap için managed\nentity'yi değiştirmemektir.

\n","resources":["$7:props:topic:questions:0:resources:1","$7:props:topic:questions:0:resources:0","$7:props:topic:questions:5:resources:0"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"product persistence context'te managed durumda. Commit öncesindeki flush'ta Hibernate onu yüklendiği andaki hâliyle karşılaştırır ve fark bulduğu için UPDATE çalıştırır.","correct":true,"misconceptionHtml":"$undefined"},{"id":"b","html":"Hibernate managed entity'lerin setter'larını izler: setPrice() çağrıldığı anda UPDATE SQL'ini veritabanına gönderir. Her setter çağrısı ayrı bir SQL komutuna karşılık gelir.","correct":false,"misconceptionHtml":"Değişikliklerin setter çağrıldığı anda SQL'e dönüştüğünü sanıyor. Hibernate değişiklikleri bellekte biriktirir ve flush sırasında (en geç commit öncesinde) entity başına bir UPDATE üretir."},{"id":"c","html":"spring.jpa.hibernate.ddl-auto=update açık olduğu için Hibernate entity'deki değişiklikleri tabloya yansıtıyor. Bu ayar none veya validate olsaydı fiyat değişmezdi.","correct":false,"misconceptionHtml":"ddl-auto'yu veri güncellemesiyle karıştırıyor. Bu ayar yalnızca şemayı (tablo ve sütunları) oluşturur, günceller veya doğrular; satırlardaki veriye dokunmaz."},{"id":"d","html":"@Transactional metot içinde değiştirilen nesneleri kendisi kaydeder: Spring metot bitince değişen her entity için arka planda repository.save() çağırır.","correct":false,"misconceptionHtml":"Değişikliği Spring'in gizli bir save() çağrısına bağlıyor. Spring'in transaction yönetimi entity'leri izlemez, yalnızca transaction'ı başlatıp commit eder. Değişikliği bulan, commit öncesindeki flush'ta Hibernate'in persistence context'idir."}]},{"id":"jpa-transaction.persistence-context.first-level-cache","level":3,"subtopic":"persistence-context","promptHtml":"$18","explanationHtml":"

Persistence context (first-level cache) her EntityManager'da vardır ve kapatılamaz. Bir id için\ntek bir managed instance tutar: find/findById önce ona bakar, entity oradaysa SQL çalıştırmadan\naynı nesneyi döner. Sınırı persistence context'in ömrüdür; Spring'de bu genellikle transaction'dır,\nyani ayrı transaction'lardaki iki findById iki ayrı SELECT çalıştırır. JPQL ve derived query'ler\n(ör. findByName) her seferinde veritabanına gider, ama dönen satır zaten managed bir entity'ye\naitse yine aynı instance'ı döndürür. Second-level cache ise bundan ayrıdır: EntityManagerFactory\ndüzeyindedir, transaction'lar arasında paylaşılır ve varsayılan olarak kapalıdır, ayrıca\nyapılandırılır.

\n","resources":["$7:props:topic:questions:0:resources:0","$7:props:topic:questions:0:resources:1"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"1 SELECT, true. İkinci findById önce persistence context'e bakar; ürün orada managed olduğu için veritabanına gitmeden aynı nesneyi döner.","correct":true,"misconceptionHtml":"$undefined"},{"id":"b","html":"2 SELECT, false. Her repository çağrısı veritabanına ayrı bir sorgu gönderir ve dönen satırdan yeni bir Product nesnesi oluşturur.","correct":false,"misconceptionHtml":"Repository'yi her çağrıda veritabanına giden basit bir DAO sanıyor. Aynı transaction içinde findById (JPA'nın find metodu) önce persistence context'e bakar; persistence context her zaman vardır, ayrıca açılmaz."},{"id":"c","html":"1 SELECT, false. İkinci çağrı veriyi Hibernate'in önbelleğinden alır ama çağırana ayrı bir kopya verir; iki nesne equals ile eşittir, == ile değildir.","correct":false,"misconceptionHtml":"Önbellekten kopya döndüğünü sanıyor. Persistence context bir id için tek bir nesne tutar ve aynı id için her zaman aynı instance'ı döner. Bu yüzden bir referansta yapılan değişiklik diğerinde de görünür."},{"id":"d","html":"2 SELECT, true. Hibernate aynı id için tek nesne tutar, ama findById her çağrıda satırı yeniden okuyup bu nesneyi veritabanındaki son değerlerle günceller.","correct":false,"misconceptionHtml":"find'ın veriyi tazelediğini sanıyor. Entity persistence context'te varsa find veritabanına gitmez; transaction sürerken başkasının yaptığı değişiklik bu nesnede görünmez. Satırı yeniden okumak için EntityManager.refresh() gerekir."}]},{"id":"jpa-transaction.persistence-context.merge-overwrites-fields","level":3,"subtopic":"persistence-context","promptHtml":"$19","explanationHtml":"

Spring Data save(), entity yeni görünüyorsa persist(), değilse merge() çağırır; @Version\nalanı yoksa yenilik id'nin null olmasına göre belirlenir. Burada id dolu olduğu için merge()\nçalışır: verilen nesnenin durumu, veritabanından yüklenen managed kopyaya olduğu gibi kopyalanır.\nSet edilmemiş alanlar da null olarak kopyalanır ve UPDATE bu değerleri yazar. Merge 'yalnız dolu\nalanları güncelle' demek değildir. Doğru yol, ürünü findById ile yükleyip yalnız istekte gelen\nalanları değiştirmektir. Managed entity'deki değişiklikleri dirty checking commit öncesinde yazar,\nistekte olmayan alanlar olduğu gibi kalır. Alanları DTO'dan entity'ye kopyalayan bir mapper\nkullanılıyorsa da hedef, yüklenmiş entity olmalıdır.

\n","resources":[{"id":"spring-data-jpa-persisting","title":"Spring Data JPA Reference: Persisting Entities","url":"https://docs.spring.io/spring-data/jpa/reference/jpa/entity-persistence.html","kind":"docs","lang":"en","levels":[2,3]},"$7:props:topic:questions:0:resources:0","$7:props:topic:questions:0:resources:1"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"Id dolu olduğu için save() merge yapar: nesnedeki tüm alanlar, boş olanlar da, kayda kopyalanır. Ürünü findById ile yükleyip yalnız name ve price'ı değiştirmek gerekir.","correct":true,"misconceptionHtml":"$undefined"},{"id":"b","html":"save() yalnız dolu alanları günceller, null'lar başka bir yerden geliyor. stock ve createdAt alanlarına @Column(nullable = false) eklemek eski değerlerin korunmasını sağlar.","correct":false,"misconceptionHtml":"save()'in kısmi güncelleme yaptığını sanıyor. Merge nesnenin tüm alanlarını kopyalar. nullable = false eski değeri korumaz; yalnız bir kısıttır ve en fazla güncellemenin hata vermesine yol açar."},{"id":"c","html":"Id elle verildiği için Hibernate eski satırı silip aynı id ile yeni bir satır ekler. Id'yi set etmeden nesneyi save()'e vermek mevcut satırı koruyarak günceller.","correct":false,"misconceptionHtml":"Güncellemenin 'sil ve yeniden ekle' olarak yapıldığını sanıyor. Hibernate mevcut satırı UPDATE eder. Id'siz bir nesne ise yeni kayıt sayılır ve tabloya ikinci bir ürün olarak eklenir."},{"id":"d","html":"stock ve createdAt lazy yüklendiği için güncelleme sırasında okunmadı ve null yazıldı. Bu iki alanı FetchType.EAGER yapmak eski değerlerin korunmasını sağlar.","correct":false,"misconceptionHtml":"Sorunu fetch stratejisine bağlıyor. stock ve createdAt hiç set edilmedi, çünkü nesne new ile oluşturuldu. Merge satırı veritabanından okur ama sonra bu boş değerleri okunan kopyanın üzerine yazar; fetch türü bunu değiştirmez. Ayrıca basit alanlar varsayılan olarak zaten hemen yüklenir."}]},{"id":"jpa-transaction.fetching.lazy-initialization","level":3,"subtopic":"fetching","promptHtml":"$1a","explanationHtml":"

Detached bir entity'nin yüklenmemiş lazy ilişkisine persistence context kapandıktan sonra\nerişilemez. Spring Boot 3'te spring.jpa.open-in-view web uygulamalarında varsayılan olarak\ntrue'dur; ayar açıkça verilmediğinde açılışta "spring.jpa.open-in-view is enabled by default"\ndiye başlayan bir uyarı loglanır. Bu yüzden LazyInitializationException çoğu projede ayar\nkapatıldığında ortaya çıkar. Kalıcı çözüm, her kullanım senaryosunun ihtiyaç duyduğu veriyi servis\nkatmanında bilinçli olarak yüklemektir. join fetch ile koleksiyon getirilirken left join fetch\nkullanılmalıdır; düz join fetch kalemi olmayan siparişi hiç döndürmez. Hibernate'in\nhibernate.enable_lazy_load_no_trans ayarı her erişimde geçici bir Session açarak hatayı susturur,\nama Hibernate de önermez; sorunu gizler ve her erişimde ayrı sorgu çalıştırır.

\n","resources":["$7:props:topic:questions:0:resources:1","$7:props:topic:questions:5:resources:0"],"fromInterview":false,"type":"open","answerHint":"medium","rubric":[{"id":"r1","html":"Sebep: items LAZY bir koleksiyondur ve findById onu yüklemez. getOrder() dönerken transaction ve onunla birlikte persistence context (Hibernate Session) kapanır, order detached olur. Controller'da koleksiyona ilk erişimde Hibernate yükleme yapacak açık bir Session bulamaz ve hata fırlatır.","weight":2,"required":true},{"id":"r2","html":"Önceden neden çalıştığı: open-in-view açıkken EntityManager HTTP isteğinin sonuna kadar açık kalır; transaction bitse de persistence context açık olduğu için lazy yükleme controller'da yapılabiliyordu. Ayar kapanınca persistence context transaction ile birlikte kapanıyor.","weight":1,"required":false},{"id":"r3","html":"Gereken veriyi transaction içinde yükleyen bir çözüm seçer ve nedenini söyler. Seçenekler: repository'de @EntityGraph(attributePaths = "items") veya left join fetch ile koleksiyonu siparişle birlikte getirmek; ya da OrderResponse'a dönüşümü servis içinde, transaction açıkken yapıp controller'a DTO dönmek. Gerekçe örneği: bu endpoint'in neyi yükleyeceği açıkça görünür, sorgu sayısı belli olur.","weight":2,"required":true},{"id":"r4","html":"Kolay ama kötü 'çözümlerden' en az birinin bedelini söyler: open-in-view'ı tekrar açmak sorunu gizler (controller'da ve JSON yazılırken fark edilmeyen sorgular, gizli N+1, veritabanı bağlantısının isteğin sonuna kadar tutulabilmesi); FetchType.EAGER koleksiyonu gerekmeyen her yerde yükler.","weight":2,"required":false}],"pass":{"minScore":5,"requireAll":["r1","r3"]},"modelAnswerHtml":"$1b"},{"id":"jpa-transaction.fetching.n-plus-one","level":3,"subtopic":"fetching","promptHtml":"$1c","explanationHtml":"

N+1, lazy bir ilişkiye döngü içinde erişildiğinde ortaya çıkar. Aynı müşteri persistence context'te bir kez yüklendiği için ek sorgu sayısı aslında farklı müşteri sayısı kadardır; yine de veriyle büyür. Kalıcı çözüm, her kullanım senaryosunun ihtiyaç duyduğu ilişkiyi sorguda açıkça istemektir (join fetch, entity graph veya DTO projection). Mapping'de ilişkileri LAZY bırakmak, gerekeni sorgu başına getirmek Hibernate'in de önerdiği yoldur. Hibernate 6'da koleksiyon join fetch edildiğinde tekrar eden ana entity'ler otomatik ayıklanır; distinct yazmak artık gerekmez.

\n","resources":["$7:props:topic:questions:0:resources:1","$7:props:topic:questions:0:resources:0"],"fromInterview":false,"type":"open","answerHint":"medium","rubric":[{"id":"r1","html":"Teşhis: N+1 problemi. Siparişler tek sorguyla gelir (1), ardından erişilen farklı müşteriler için ayrı ayrı sorgular çalışır (N). Sorgu sayısı veriyle büyüdüğü için az veriyle testte fark edilmez, canlıda yavaşlatır.","weight":2,"required":true},{"id":"r2","html":"Sebep: customer LAZY olduğu için ilk sorgu müşteri verisini getirmez; customer alanı henüz yüklenmemiş bir proxy'dir. Döngüdeki o.getCustomer().getName() çağrısı proxy'yi başlatır ve o anda o müşteri için bir SELECT atılır.","weight":2,"required":true},{"id":"r3","html":"Müşterileri ana sorguyla birlikte getiren somut bir çözüm verir: join fetch içeren bir @Query, @EntityGraph(attributePaths = "customer") veya yalnızca gereken alanları seçen bir DTO projection (select new ...). Kod yazması gerekmez; yöntemi adıyla ve ne yaptığıyla anlatması yeterlidir.","weight":2,"required":false},{"id":"r4","html":"Batch fetching'i seçenek olarak bilir ve bedelini söyler: @BatchSize veya hibernate.default_batch_fetch_size sorguyu değiştirmeden müşterileri id listesiyle toplu yükler; sorgu sayısını azaltır ama tek sorguya indirmez.","weight":1,"required":false},{"id":"r5","html":"FetchType.EAGER yapmanın çözüm olmadığını açıklar: JPQL/derived query'de join fetch yazılmazsa EAGER ilişki yine ayrı sorgularla yüklenir; üstelik ilişkiye ihtiyaç duyulmayan her yerde de yüklenir.","weight":1,"required":false},{"id":"r6","html":"Bu endpoint için seçimini gerekçelendirir. Örnek: yalnız sipariş id'si, müşteri adı ve tutar gerektiği için DTO projection en hafif seçenektir; entity'ler aynı işlemde değiştirilecek veya başka yerde kullanılacaksa join fetch/@EntityGraph daha uygundur.","weight":1,"required":false}],"pass":{"minScore":4,"requireAll":["r1","r2"]},"modelAnswerHtml":"$1d"},{"id":"jpa-transaction.entity-mapping.cascade-on-many-to-one","level":4,"subtopic":"entity-mapping","promptHtml":"$1e","explanationHtml":"$1f","resources":["$7:props:topic:questions:0:resources:0","$7:props:topic:questions:0:resources:1"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"Silme customer'a da yayılır ve Hibernate müşteriyi de silmeye çalışır. Müşterinin başka siparişi varsa foreign key ihlaliyle tüm işlem geri alınır; yoksa müşteri sessizce silinir.","correct":true,"misconceptionHtml":"$undefined"},{"id":"b","html":"Yalnızca sipariş ve kalemleri silinir. Cascade her zaman parent'tan child'a, yani @OneToMany tarafından karşıya doğru çalışır; @ManyToOne üzerine yazılan cascade silmede dikkate alınmaz.","correct":false,"misconceptionHtml":"Cascade yönünün ilişki türünden geldiğini sanıyor. Cascade, anotasyonun yazıldığı taraftan hedef entity'ye doğru uygulanır; @ManyToOne üzerindeki REMOVE siparişten müşteriye yayılır."},{"id":"c","html":"Yalnızca sipariş ve kalemleri silinir. Silme bir ilişkiye ancak orphanRemoval = true ile yayılır; customer ilişkisinde bu ayar olmadığı için cascade yalnızca kaydetme işlemlerini taşır.","correct":false,"misconceptionHtml":"Cascade REMOVE ile orphanRemoval'ı karıştırıyor. CascadeType.ALL, REMOVE'u da içerir. orphanRemoval ise child ilişkiden koparıldığında (koleksiyondan çıkarıldığında veya referans null yapıldığında) onu silen ayrı bir kuraldır."},{"id":"d","html":"Sipariş, müşteri ve müşterinin diğer tüm siparişleri silinir. Cascade, silinen müşteriye foreign key ile bağlı kayıtları da bulup silerek veritabanını tutarlı bırakır.","correct":false,"misconceptionHtml":"JPA cascade'ini veritabanındaki ON DELETE CASCADE gibi sanıyor. Cascade yalnızca mapping'de tanımlı ilişkileri izler; Customer'da siparişlere ilişki olmadığı için diğer siparişler silinmez, silme foreign key ihlaline takılır."}]},{"id":"jpa-transaction.transactions.inner-exception-caught","level":4,"subtopic":"transactions","promptHtml":"$20","explanationHtml":"

Varsayılan propagation REQUIRED'dır: redeem() yeni transaction açmaz, placeOrder()'ın\ntransaction'ına katılır. Her @Transactional metot yine de kendi sınırında rollback kuralını\nuygular. RuntimeException redeem()'in proxy'sinden dışarı çıkarken Spring ortak transaction'ı\nrollback-only işaretler. placeOrder() exception'ı yakalayıp devam etse de commit denemesi\nrollback'e döner. Spring, çağıran taraf commit yapıldığını sanmasın diye bilerek\nUnexpectedRollbackException fırlatır.

\n

Düzeltme yolları: beklenen bir iş sonucunu exception ile transaction sınırından geçirmemek (örneğin\nkuponun geçerliliğini önce boolean dönen bir metotla kontrol etmek); gerçekten gerekiyorsa\nrollback kuralını iç metotta değiştirmek (redeem() üzerinde noRollbackFor, dış metotta değil);\nkupon işlemi siparişten bağımsız commit edilmeliyse REQUIRES_NEW.

\n","resources":["$7:props:topic:questions:5:resources:0"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"redeem() aynı transaction'a katılır; exception onun transactional sınırından çıkarken Spring ortak transaction'ı rollback-only işaretler. Dışta yakalamak bu işareti kaldırmaz.","correct":true,"misconceptionHtml":"$undefined"},{"id":"b","html":"redeem() kendi alt transaction'ını açar. Bu alt transaction geri alınınca Spring, veriler tutarlı kalsın diye ona bağlı olan dış transaction'ı da otomatik olarak iptal eder.","correct":false,"misconceptionHtml":"Varsayılan REQUIRED'ı dış transaction'a bağlı bir alt transaction sanıyor. REQUIRED yeni bir transaction açmaz, mevcut transaction'a katılır; iki metot aynı fiziksel transaction'ı paylaşır. Bağımsız bir transaction REQUIRES_NEW ile açılır."},{"id":"c","html":"Kupon ve sipariş aynı satırlara yazdığı için veritabanı bir kilit çakışması (deadlock) algılayıp transaction'ı geri aldı; Spring bu durumu UnexpectedRollbackException olarak raporlar.","correct":false,"misconceptionHtml":"Rollback'i veritabanına bağlıyor. Mesajdaki 'marked as rollback-only' ifadesi, rollback kararını Spring'in kendisinin verdiğini gösterir. Veritabanı kaynaklı bir kilit hatası kendi exception'ıyla görünürdü; burada tek bir istek var ve çakışan başka bir transaction yok."},{"id":"d","html":"Transactional bir metodun içinde fırlayan her RuntimeException, nerede yakalanırsa yakalansın transaction'ı rollback-only yapar; bu yüzden placeOrder() içindeki try/catch işe yaramaz.","correct":false,"misconceptionHtml":"Sonuç doğru ama sebep yanlış: rollback kararının exception fırladığı anda verildiğini sanıyor. Spring rollback kararını yalnız exception bir @Transactional metodun (proxy'nin) sınırından dışarı çıkarken verir. redeem() @Transactional olmasaydı, exception hiçbir transaction sınırından geçmeden placeOrder()'da yakalanır ve sipariş commit edilirdi."}]},{"id":"jpa-transaction.transactions.report-consistency","level":4,"subtopic":"transactions","promptHtml":"$21","explanationHtml":"

READ COMMITTED'de her sorgu, başladığı anda commit edilmiş veriyi görür; aynı transaction içindeki\niki ardışık SELECT, arada başka bir transaction commit ederse farklı veri görebilir. Burada iki\nsorgu arasında yeni bir satır eklendiği için bu bir phantom read'dir. En sade ve her veritabanında\naynı çalışan düzeltme, iki değeri tek bir okumaya dayandırmaktır: toplamı okunan listeden hesaplamak\n(ya da ikisini tek sorguda almak).

\n

Isolation yükseltmek de bir seçenektir, ama davranışı veritabanına göre değişir. SQL standardında\nREPEATABLE READ phantom read'e izin verir, bu yüzden standart garanti SERIALIZABLE'dadır.\nPostgreSQL'in REPEATABLE READ'i phantom'ı da engeller. MySQL InnoDB'nin varsayılanı REPEATABLE READ\nolduğu için düz SELECT'ler aynı transaction'da zaten aynı anlık görüntüyü okur. SERIALIZABLE ise\nserialization hatası ve yeniden deneme yükü getirebilir.

\n","resources":[{"id":"postgresql-transaction-isolation","title":"PostgreSQL Documentation: Transaction Isolation","url":"https://www.postgresql.org/docs/current/transaction-iso.html","kind":"docs","lang":"en","levels":[3,4]},"$7:props:topic:questions:5:resources:0"],"fromInterview":false,"type":"mc","allowUnsure":true,"shuffle":true,"options":[{"id":"a","html":"READ COMMITTED'de her sorgu başladığı anda commit edilmiş veriyi görür; arada eklenen sipariş yalnız listeye girer. Toplamı okunan listeden hesaplamak iki değeri aynı veriye dayandırır.","correct":true,"misconceptionHtml":"$undefined"},{"id":"b","html":"Sebep: SUM sorgusu satırları kilitlemediği için arada sipariş eklenebildi. Düzeltme: findByDay'i @Lock(LockModeType.PESSIMISTIC_READ) ile çalıştırıp okunan satırları kilitlemek.","correct":false,"misconceptionHtml":"Satır kilidinin iki ayrı sorguyu tutarlı yaptığını sanıyor. Kilit ikinci sorguda ve yalnız o anda var olan satırlara konur; toplam zaten hesaplanmıştır ve iki sorgu arasında eklenen yeni satırı engellemez. Çözüm iki değeri aynı okumaya dayandırmaktır."},{"id":"c","html":"Aynı transaction'daki sorgular normalde aynı anlık görüntüyü görür. Tutarsızlık, readOnly = true yüzünden her sorgunun ayrı bir transaction'da çalışmasından doğar; readOnly kaldırılmalı.","correct":false,"misconceptionHtml":"Tek bir transaction'ın kendiliğinden tutarlı bir anlık görüntü sağladığını sanıyor. READ COMMITTED'de aynı transaction içindeki her sorgu o anda commit edilmiş veriyi görür. readOnly transaction'ı bölmez; altyapıya veri değiştirilmeyeceğini bildiren bir ipucudur."},{"id":"d","html":"Hibernate toplam sorgusunun sonucunu first-level cache'ten döndürüyor, liste ise veritabanından geliyor. Sorgulardan önce entityManager.clear() çağırmak iki değeri aynı veriye dayandırır.","correct":false,"misconceptionHtml":"First-level cache'in sorgu sonuçlarını sakladığını sanıyor. Persistence context entity'leri id'ye göre tutar; JPQL ve toplama (SUM) sorguları her çağrıda veritabanına gider. Sorun önbellek değil, iki sorgunun farklı anlarda commit edilmiş veriyi görmesi."}]},{"id":"jpa-transaction.transactions.audit-log-on-failure","level":4,"subtopic":"transactions","promptHtml":"$22","explanationHtml":"

REQUIRED tüm işi tek bir fiziksel transaction'da toplar; hepsi birlikte commit veya rollback olur. Bir kaydın ana işten bağımsız kalıcı olması gerekiyorsa ya ayrı bir fiziksel transaction (REQUIRES_NEW) ya da ana transaction'ın dışında yazma gerekir. REQUIRES_NEW bedelsiz değildir: dış transaction'ın connection'ı açık kalırken ikinci bir connection ister. JPA ile NESTED (savepoint) seçeneği pratikte kullanılmaz; Spring'in JpaTransactionManager'ında varsayılan olarak kapalıdır.

\n","resources":["$7:props:topic:questions:5:resources:0"],"fromInterview":false,"type":"open","answerHint":"medium","rubric":[{"id":"r1","html":"Sebep: audit satırı siparişle aynı transaction'da yazılıyor (save() varsayılan REQUIRED ile mevcut transaction'a katılır). OutOfStockException metottan çıkınca transaction rollback olur ve audit satırı da geri alınır.","weight":2,"required":true},{"id":"r2","html":"Audit kaydını sipariş transaction'ından bağımsız commit eden bir çözüm önerir: audit yazımını @Transactional(propagation = REQUIRES_NEW) bir metoda almak (dış transaction askıya alınır, audit kendi transaction'ında commit olur, dış rollback onu etkilemez) veya audit'i sipariş transaction'ının dışında, transaction'sız bir üst katmandan kendi transaction'ında yazmak.","weight":2,"required":true},{"id":"r3","html":"Yeni transaction'ın gerçekten açılması için çağrının proxy'den geçmesi gerektiğini gözetir: REQUIRES_NEW metodu (veya placeOrder()'ı saran üst katman) ayrı bir bean'dedir; aynı sınıftan this ile çağrılmaz.","weight":1,"required":false},{"id":"r4","html":"Bedeli tartar, en az birini gerekçesiyle söyler: REQUIRES_NEW dış transaction'ın connection'ı açıkken ikinci bir connection alır, yoğun trafikte pool tükenebilir ve thread'ler birbirini bekleyerek kilitlenebilir; audit yazımı hata verirse exception siparişe yayılır ve yakalanmazsa siparişi de geri aldırır.","weight":2,"required":false},{"id":"r5","html":"En az iki yolu karşılaştırıp gerekçeli bir seçim yapar. Örnek: REQUIRES_NEW çağrı yerinde basittir ama connection bedeli vardır; audit'i transaction dışında yazmak aynı anda iki connection tutmaz ve denemenin sonucunu (başarılı/başarısız, sebep) kaydetmeyi kolaylaştırır ama bir katman daha ister.","weight":1,"required":false}],"pass":{"minScore":6,"requireAll":["r1","r2"]},"modelAnswerHtml":"$23"},{"id":"jpa-transaction.transactions.concurrent-stock-update","level":4,"subtopic":"transactions","promptHtml":"$24","explanationHtml":"

@Transactional işlemleri atomik yapar, ama eşzamanlı iki transaction'ın aynı değeri okuyup\nüzerine yazmasını tek başına engellemez. Çözüm; çakışmayı sonradan fark edip reddetmek\n(optimistic, @Version), baştan kilitlemek (pessimistic) ya da kontrol ile yazmayı tek atomik\nsorguda birleştirmektir. Hangisinin seçileceği çakışmanın ne sıklıkla beklendiğine bağlıdır.

\n

Isolation'ın etkisi veritabanına göre değişir. PostgreSQL'in varsayılanı READ COMMITTED'de ikinci\nUPDATE birincinin commit'ini bekler, sonra üzerine yazar; REPEATABLE READ'de "could not serialize\naccess due to concurrent update" hatası verir, yine retry gerekir. MySQL InnoDB'nin varsayılanı\nREPEATABLE READ bu deseni engellemez, çünkü UPDATE başka transaction'ların commit ettiği son satır\nüzerinde çalışır. synchronized ise yalnız tek bir JVM'deki thread'leri sıraya sokar; ayrıca\nkilit metot dönünce bırakılır, commit ise proxy'de daha sonra olur.

\n","resources":["$7:props:topic:questions:0:resources:1","$7:props:topic:questions:5:resources:0"],"fromInterview":false,"type":"open","answerHint":"medium","rubric":[{"id":"r1","html":"Teşhis: iki transaction aynı stok değerini (1) okur, ikisi de kontrolü geçer, ikisi de 0 yazar; sonra yazan öncekinin güncellemesini ezer (lost update). @Transactional tek başına eşzamanlı okuma-kontrol-yazma desenini korumaz.","weight":2,"required":true},{"id":"r2","html":"En az bir doğru çözüm önerir ve çakışmayı nasıl engellediğini söyler: @Version ile optimistic locking (ikinci commit eski versiyonla güncelleme yapamaz, ObjectOptimisticLockingFailureException alır), PESSIMISTIC_WRITE ile okuma (satır kilidi; ikinci istek bekler, sonra güncel stoğu okur) veya tek sorguda koşullu güncelleme (UPDATE ... SET stock = stock - :q WHERE id = :id AND stock >= :q, etkilenen satır sayısına bakmak).","weight":2,"required":true},{"id":"r3","html":"Seçimini çakışma sıklığına göre gerekçelendirir ve bedelleri tartar: optimistic kilit tutmaz ama çakışmada hata verir, işlem yeniden denenmeli veya kullanıcıya bildirilmeli, sık çakışmada çok retry olur; pessimistic doğru sıraya sokar ama istekler bekler, kilit transaction boyunca tutulur, transaction kısa tutulmalı ve deadlock riski vardır.","weight":2,"required":false},{"id":"r4","html":"Isolation seviyesini yükseltmenin tek başına güvenilir bir çözüm olmadığını bilir: davranışı veritabanına göre değişir (bazısı çakışan güncellemeyi hatayla reddeder ve retry gerekir, bazısı bu deseni hiç engellemez); bu yüzden açık bir kilit, versiyon kontrolü veya koşullu güncelleme tercih edilir.","weight":1,"required":false}],"pass":{"minScore":5,"requireAll":["r1","r2"]},"modelAnswerHtml":"$25"}]}}]