Birden fazla değişikliği birlikte kaydedin

Aynı iş birden fazla veritabanı değişikliği yapıyorsa bunların birbirinden bağımsız kalıp kalamayacağını belirleyin. İkinci değişiklik başarısız olduğunda birincinin kalıcı kalması işinizi bozuyorsa transaction gerekir. Başarılı tamamlanmada değişiklikler birlikte kalıcılaşır (commit); hata halinde geri alınır (rollback).

Tek başına Try/Catch, hata mesajı veya yeniden deneme ayarı transaction oluşturmaz. SQL adımlarının gerçekten aynı transaction kapsamına katılması gerekir.

1. Hangi değişiklikler birlikte olmalı?

İşin tutarlı sayıldığı en küçük değişiklik grubunu belirleyin. Ana kayıt ve ayrıntıları, durum değişikliği ve ona bağlı miktar hareketi gibi birbirini tamamlayan yazmalar buna örnektir. Bağımsız işleri gereksiz yere uzun bir transaction içinde tutmayın.

Ön doğrulama, büyük dosya okuma veya yavaş dış servis çağrısını mümkünse kilit tutulan bölümden önce tamamlayın. Transaction içindeki süre uzadıkça diğer isteklerin beklemesi ve bağlantı havuzunun dolması kolaylaşır.

2. Bağlantı ve transaction ayarını hazırlayın

Yerel SQL transaction’ında bir transaction manager, aynı DataSource üzerinden açılan işi yönetir. Projede bağlantıya işaret eden manager ve akışın kullanacağı politika tanımlanır. SQL adımları da aynı DataSource nesnesini kullanmalıdır. Aynı sunucuya giden iki ayrı bağlantı tanımı otomatik olarak aynı transaction değildir.

Mevcut bir proje bu ayarları zaten sağlıyorsa onları kullanın. Henüz yoksa bağlantı yöneticisi ve politika bean’lerini kendi bağlantınıza göre hazırlayın. Çalışan bir tanımın nasıl kurulduğunu örneğin transaction ayarında görebilirsiniz; o tanımdaki bağlantı adı ve sürücü sizin ortamınıza uyarlanır.

3. Akışta transaction sınırını koyun

1. Birlikte yapılacak SQL işlemlerini aynı iş akışında gruplayın.
2. İlk yazmadan önce Transacted adımını kullanıp hazırlanan transaction politikasına referans verin.
3. Kapsamdaki SQL adımlarının aynı bağlantıyı seçtiğini kontrol edin.
4. Başarı ve başarısızlık yollarını belirleyin.
5. Ayrı okuma istekleriyle hem commit hem rollback sonucunu doğrulayın.

Bir politikaya referans veren adımın biçimi aşağıdaki gibidir; transactionPolicy, projenizde tanımladığınız bean adı olmalıdır:

- transacted:
    ref: transactionPolicy

Bu adımı tek başına kopyalamak bağlantı veya manager oluşturmaz. Politika, bağlantı ve hata davranışı birlikte hazırlanır. Ayrı akışları aynı proje içinde direct: ile eşzamanlı çağırabilirsiniz; mesajı asenkron kuyruğa vermek aynı transaction’ın otomatik devamı sayılmaz.

4. İş hatası ile teknik hatayı ayırın

Teknik bir exception transaction sınırından başarısızlık olarak çıktığında manager geri alma yapabilir. İş kuralı reddi ise yalnızca bir 4xx yanıtı olarak hazırlanmış olabilir; HTTP durum kodu tek başına rollback talimatı değildir.

Bir iş kuralı nedeniyle önceki yazmaların da geri alınması gerekiyorsa açıkça Rollback kullanın. markRollbackOnly, transaction’ı geri alınacak olarak işaretlemeyi sağlar. Hata yanıtını ne zaman hazırladığınıza ve sonraki adımların çalışıp çalışmayacağına dikkat edin.

Hataları transaction’ın içinde yakalayıp “işlendi” diye başarıya çevirirseniz commit davranışını değiştirebilirsiniz. Kullanıcıya güvenli bir hata yanıtı döndürmekle işlemi başarılı kabul etmeyi ayırın. Uygulamalı örnek, teknik hatayı transaction çağrısından sonra dış Catch içinde yanıta çevirir.

5. Geri almayı veride kanıtlayın

Deneme ortamında şu sırayı izleyin:

1. Değişecek kayıtların başlangıç durumunu ayrı bir okumayla alın.
2. İşlemi normal girdide çalıştırın; bütün değişikliklerin birlikte kalıcılaştığını kontrol edin.
3. İlk yazmadan sonra, henüz iş tamamlanmadan kontrollü hata üretin.
4. İstek bittikten sonra yeni bir okuma yapın; önceki yazmanın da kalıcı kalmadığını doğrulayın.
5. Yeniden denemenin aynı işi ikinci kez uygulamamasını ayrıca sınayın.

Başarısız log satırı veya ekrandaki kırmızı sonuç bu veri kontrolünün yerini tutmaz. Başka transaction’ın yaptığı meşru değişiklikleri de kendi denemenizin sonucu gibi yorumlamamak için deneme kayıtlarını ayırın.

6. Transaction’ın dışındaki etkileri planlayın

Bu yerel transaction yalnızca aynı yönetime katılan veritabanı işlemlerini kapsar. Başka veritabanı, gönderilmiş HTTP isteği, e-posta veya bağımsız kuyruk mesajı otomatik geri alınmaz. Dış sisteme bildirim gereken işlerde commit ile teslim arasındaki hata ihtimalini ayrıca ele alın.

Gönderilecek işi aynı transaction içinde bir görev tablosuna yazıp sonradan teslim etmek bu boşluğu yönetmenin bir yoludur. Bu yaklaşımda da tekrar teslimat ve alıcının aynı işi iki kez uygulamaması gerekir. Ayrı bir tasarım gerektiren bu davranışı yalnızca Transacted ekleyerek kazanmış olmazsınız.

Transaction, aynı isteğin daha sonra tekrar gelmesini de engellemez. İş kimliği ve tekrar deneme kararlarını birlikte verin. Baştan sona deneyebileceğiniz commit/rollback adımları sipariş ve stok örneğinde bulunur.