Yanıtlar:
İyi soru, cevaplamak önemsiz olmasa da.
İşlemlerin birbiriyle nasıl ilişkili olduğunu tanımlar. Ortak seçenekler:
Required: Kod her zaman bir işlemde çalışır. Yeni bir işlem oluşturur veya varsa bir işlemi yeniden kullanır.Requires_new: Kod her zaman yeni bir işlemde çalışır. Varsa, mevcut işlemi askıya alır.İşlemler arasındaki veri sözleşmesini tanımlar.
Read Uncommitted: Kirli okumalara izin verir.Read Committed: Kirli okumalara izin vermez.Repeatable Read: Bir satır aynı işlemde iki kez okunursa, sonuç her zaman aynı olur.Serializable: Tüm işlemleri sırayla gerçekleştirir.Çok kademeli bir uygulamada farklı seviyeler farklı performans özelliklerine sahiptir. Bence dirty readskavramı anlarsanız iyi bir seçenek seçebilirsiniz.
Kirli bir okumanın ne zaman gerçekleşebileceğine örnek:
thread 1 thread 2
| |
write(x) |
| |
| read(x)
| |
rollback |
v v
value (x) is now dirty (incorrect)Bu nedenle Read Committed, yalnızca diğer çalışan işlemler tarafından zaten taahhüt edilmiş değerleri, yayılma düzeyi ile birlikte okumanızı sağlayan bir aklı başında varsayılan (böyle bir talep edilebilirse) olabilir Required. Ardından uygulamanızın başka ihtiyaçları varsa oradan çalışabilirsiniz.
Rutine girerken her zaman yeni bir işlemin nerede oluşturulacağı provideServiceve ayrılırken tamamlanacağına dair pratik bir örnek :
public class FooService {
private Repository repo1;
private Repository repo2;
@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
repo1.retrieveFoo();
repo2.retrieveFoo();
}
}Bunun yerine kullanmıştı Required, işlem açık kalacağını rutin girerken işlem zaten açık olsaydı. rollbackAynı işlemde birden fazla yürütme yer alabileceğinden , a sonucunun farklı olabileceğini de unutmayın .
Davranışı bir testle kolayca doğrulayabilir ve sonuçların yayılma seviyelerine göre nasıl değiştiğini görebiliriz:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="classpath:/fooService.xml")
public class FooServiceTests {
private @Autowired TransactionManager transactionManager;
private @Autowired FooService fooService;
@Test
public void testProvideService() {
TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
fooService.provideService();
transactionManager.rollback(status);
// assert repository values are unchanged ...
}Yayılma seviyesi ile
Requires new: Biz beklenir fooService.provideService()oldu DEĞİL buna kendi alt işlem var oluşturulan beri geri alındı.
Required: her şeyin geri alındığını ve destek mağazasının değişmediğini umuyoruz.
sessionFactory.getCurrentTransaction(), eklendiğinden beri HibernateTemplateişlemleri yönetmek için artık çalıştırmaya gerek yok. Kaldırdım :)
PROPAGATION_REQUIRED = 0 ; Yöntem M1 için DataSourceTransactionObject T1 zaten başlatılmışsa, başka bir Yöntem M2 İşlem nesnesi için gerekliyse, yeni bir İşlem nesnesi oluşturulmaz. M2 için nesne nesnesi T1 kullanılır
PROPAGATION_MANDATORY = 2 ; yöntemi bir işlem içinde çalıştırılmalıdır. Hiçbir işlem yapılmıyorsa, bir istisna atılır
PROPAGATION_REQUIRES_NEW = 3 ; DataSourceTransactionObject T1, Yöntem M1 için zaten başlatıldıysa ve devam ediyorsa (M1 yöntemi yürütülüyorsa) M2'nin başka bir yöntemi yürütülmeye başlarsa, M2, M2 için yeni DataSourceTransactionObject T2 yöntemi ile T1, kendi işlem bağlamında çalışır.
PROPAGATION_NOT_SUPPORTED = 4 ; DataSourceTransactionObject T1 Yöntem M1 için zaten başlatılmışsa, başka bir yöntem M2 eşzamanlı olarak çalıştırılırsa, M2 işlem bağlamında çalışmamalıdır. M2 tamamlanana kadar T1 askıya alınır.
PROPAGATION_NEVER = 5 ; Yöntemlerin hiçbiri işlem bağlamında çalışmaz.
Bir yalıtım düzeyi: Bir işlemin, eşzamanlı diğer işlemlerin faaliyetlerinden ne kadar etkilenebileceği ile ilgilidir. Verileri birçok tabloda tutarlı bir durumda bırakarak tutarlılığı destekler. Bir veritabanındaki satırları ve / veya tabloları kilitlemeyi içerir.
Birden fazla işlemle ilgili sorun
Senaryo 1.T1 işlemi, başka bir eşzamanlı T2 işlemi tarafından yazılan Tablo A1'den veri okursa, T2'nin geri dönüşü durumunda, T1 tarafından elde edilen veriler geçersizdir.Eg a = 2, orijinal verilerdir. T2 geri dönüşü tarafından yazılırsa, o zaman a = 1 DB'de a = 2'ye geri alınır.
Scenario2 T1 okuma tablo A1.Eg verileri güncelledi tablo A1.Because T2 farklıdır sahip olduğunu tablo A1.Then üzerinde .Eğer T1 işlem eşzamanlı başka bir işlem A1.If tablodan verileri okur (T2) güncelleme veri veri T1 ise a = 1'i okuyun ve T2, a = 2'yi güncelledi. Sonra a! = b.
Senaryo 3.T1 işlemi belirli sayıda satırla tablo A1'deki verileri okursa. Başka bir eşzamanlı işlem (T2) A1 tablosuna daha fazla satır eklerse T1 tarafından okunan satır sayısı A1 tablosundaki satırlardan farklıdır
Senaryo 1'e Kirli okumalar denir .
Senaryo 2'ye tekrarlanamayan okumalar denir .
Senaryo 3'e Phantom okumaları denir .
Bu nedenle, yalıtım düzeyi Senaryo 1, Senaryo 2, Senaryo 3'ün önlenebileceği kapsamdır. Kilitleme uygulayarak tam izolasyon seviyesi elde edebilirsiniz. Aynı verilerin aynı anda okunmasını ve yazılmasını engeller, ancak performansı etkiler. Yalıtım seviyesi, ne kadar izolasyonun gerekli olduğu uygulamaya bağlıdır.
ISOLATION_READ_UNCOMMITTED : Henüz tamamlanmamış değişiklikleri okumaya izin verir. Senaryo 1, Senaryo 2, Senaryo 3'ten muzdarip
ISOLATION_READ_COMMITTED : Yürütülen eşzamanlı işlemlerden okumalara izin verir. Senaryo 2 ve Senaryo 3'den muzdarip olabilir. Çünkü diğer işlemler verileri güncelliyor olabilir.
ISOLATION_REPEATABLE_READ : Aynı alanın çoklu olarak okunması, kendisi tarafından değiştirilene kadar aynı sonuçları verir. Senaryo 3'ten muzdarip olabilir. Çünkü diğer işlemler verileri ekliyor olabilir
ISOLATION_SERIALIZABLE : Senaryo 1, Senaryo 2, Senaryo 3 asla gerçekleşmez.Tam izolasyondur.Tam kilitleme içerir.Kilitleme nedeniyle performansı etkiler.
Kullanarak test edebilirsiniz
public class TransactionBehaviour {
// set is either using xml Or annotation
DataSourceTransactionManager manager=new DataSourceTransactionManager();
SimpleTransactionStatus status=new SimpleTransactionStatus();
;
public void beginTransaction()
{
DefaultTransactionDefinition Def = new DefaultTransactionDefinition();
// overwrite default PROPAGATION_REQUIRED and ISOLATION_DEFAULT
// set is either using xml Or annotation
manager.setPropagationBehavior(XX);
manager.setIsolationLevelName(XX);
status = manager.getTransaction(Def);
}
public void commitTransaction()
{
if(status.isCompleted()){
manager.commit(status);
}
}
public void rollbackTransaction()
{
if(!status.isCompleted()){
manager.rollback(status);
}
}
Main method{
beginTransaction()
M1();
If error(){
rollbackTransaction()
}
commitTransaction();
}
}İzolasyon ve yayılma için sonuçları farklı değerlerle ayıklayabilir ve görebilirsiniz.
Her bir parametre hakkında yeterli açıklama diğer cevaplarla verilir; Gerçek bir dünya örneği istediniz, ancak farklı yayılma seçeneklerinin amacını açıklayan örnek :
Kullanıcıya bir onay e-postasının gönderildiği bir kayıt hizmetini uygulamaktan sorumlu olduğunuzu varsayalım . Biri kullanıcıyı kaydetmek ve diğeri e-posta göndermek için olmak üzere iki hizmet nesnesiyle karşılaşırsınız, bunlardan ikincisi ilkinin içinde çağrılır. Örneğin böyle bir şey:/* Sign Up service */
@Service
@Transactional(Propagation=REQUIRED)
class SignUpService{
...
void SignUp(User user){
...
emailService.sendMail(User);
}
}
/* E-Mail Service */
@Service
@Transactional(Propagation=REQUIRES_NEW)
class EmailService{
...
void sendMail(User user){
try{
... // Trying to send the e-mail
}catch( Exception)
}
}İkinci hizmetin REQUIRES_NEW yayılım türü olduğunu fark etmiş olabilirsiniz ve ayrıca bir istisna atar (SMTP sunucusu, geçersiz e-posta veya diğer nedenler). Muhtemelen tüm sürecin geri alınmasını istemezsiniz, örneğin kullanıcı bilgilerinin veritabanından veya diğer şeylerden kaldırılması; bu nedenle ikinci servisi ayrı bir işlemde çağırırsınız.
Örneğimize geri dönersek, bu sefer veritabanı güvenliği konusunda endişe duyuyorsunuz, bu yüzden DAO sınıflarınızı şu şekilde tanımlıyorsunuz:/* User DAO */
@Transactional(Propagation=MANDATORY)
class UserDAO{
// some CRUD methods
}Yani bir DAO nesnesi ve dolayısıyla db'ye potansiyel bir erişim oluşturulduğunda, çağrının hizmetlerimizden birinin içinden yapıldığından emin olmamız gerekir, bu da canlı bir işlemin var olması anlamına gelir; aksi takdirde bir istisna oluşur. Bu nedenle yayılma ZORUNLU tiptedir .
Yalıtım düzeyi , bir veri deposu tarafından bazı veri havuzunda yapılan değişikliklerin eşzamanlı olarak diğer eşzamanlı işlemleri nasıl etkilediğini ve ayrıca değiştirilen verilerin diğer işlemler için nasıl ve ne zaman kullanılabilir olacağını tanımlar. Spring çerçevesini kullanarak bir işlem tanımladığımızda, aynı işlemin hangi yalıtım seviyesinde yürütüleceğini de yapılandırabiliriz.
@Transactional(isolation=Isolation.READ_COMMITTED)
public void someTransactionalMethod(Object obj) {
}READ_UNCOMMITTED yalıtım düzeyi, bir işlemin diğer işlemler tarafından hala onaylanmamış verileri okuyabileceğini belirtir.
READ_COMMITTED yalıtım düzeyi, bir işlemin henüz diğer işlemler tarafından gerçekleştirilmeyen verileri okuyamayacağını belirtir.
REPEATABLE_READ yalıtım düzeyi, bir işlem veritabanından bir kaydı birden çok kez okursa, tüm bu okuma işlemlerinin sonucunun her zaman aynı olması gerektiğini belirtir.
SERİLEŞTİRİLEBİLİR izolasyon seviyesi tüm izolasyon seviyelerinin en kısıtlayıcısıdır. İşlemler tüm seviyelerde kilitleme ile (okuma, aralık ve yazma kilitleme) gerçekleştirilir, böylece seri bir şekilde yürütülmüş gibi görünürler.
Yayılma , iş yöntemlerinin hem mantıksal hem de fiziksel işlemlere nasıl dahil edileceğine karar verme yeteneğidir.
Bahar GEREKLİ davranışı, geçerli fasulye yöntemi yürütme bağlamında zaten açık bir işlem varsa aynı işlemin kullanılacağı anlamına gelir.
REQUIRES_NEW davranışı, kapsayıcı tarafından her zaman yeni bir fiziksel işlemin oluşturulacağı anlamına gelir.
NESTED davranışı, aynı fiziksel işlemi kullanmak için iç içe geçen Bahar işlemlerini yapar, ancak iç işlemlerin dış işlemlerden bağımsız olarak geri alınabilmesi için iç içe çağrılar arasında kayıt noktaları belirler.
ZORUNLU davranış, varolan bir açık işlemin zaten var olması gerektiğini belirtir. Değilse konteyner tarafından bir istisna atılır.
ASLA davranışı, mevcut bir açık işlemin zaten mevcut olmaması gerektiğini belirtir. Bir işlem varsa, kapsayıcı tarafından bir istisna atılır.
NOT_SUPPORTED davranışı, herhangi bir işlemin kapsamı dışında yürütülür. Açılmış bir işlem zaten varsa duraklatılır.
SUPPORTS davranışı, açık bir işlem zaten varsa bir işlem kapsamında yürütülür. Önceden açılmış bir işlem yoksa yöntem yine de işlem dışı bir şekilde yürütülür.
İşlem, veritabanıyla bir çalışma birimini temsil eder.
TransactionDefinitionYay uyumlu işlem özelliklerini tanımlayan yay arayüzünde. @Transactionalek açıklama, bir yöntem veya sınıftaki işlem özelliklerini açıklar.
@Autowired
private TestDAO testDAO;
@Transactional(propagation=TransactionDefinition.PROPAGATION_REQUIRED,isolation=TransactionDefinition.ISOLATION_READ_UNCOMMITTED)
public void someTransactionalMethod(User user) {
// Interact with testDAO
}Yayılma (Üreme): işlemler arası ilişki için kullanılır. (java inter thread iletişimine benzer)
+-------+---------------------------+------------------------------------------------------------------------------------------------------+
| value | Propagation | Description |
+-------+---------------------------+------------------------------------------------------------------------------------------------------+
| -1 | TIMEOUT_DEFAULT | Use the default timeout of the underlying transaction system, or none if timeouts are not supported. |
| 0 | PROPAGATION_REQUIRED | Support a current transaction; create a new one if none exists. |
| 1 | PROPAGATION_SUPPORTS | Support a current transaction; execute non-transactionally if none exists. |
| 2 | PROPAGATION_MANDATORY | Support a current transaction; throw an exception if no current transaction exists. |
| 3 | PROPAGATION_REQUIRES_NEW | Create a new transaction, suspending the current transaction if one exists. |
| 4 | PROPAGATION_NOT_SUPPORTED | Do not support a current transaction; rather always execute non-transactionally. |
| 5 | PROPAGATION_NEVER | Do not support a current transaction; throw an exception if a current transaction exists. |
| 6 | PROPAGATION_NESTED | Execute within a nested transaction if a current transaction exists. |
+-------+---------------------------+------------------------------------------------------------------------------------------------------+İzolasyon : İzolasyon, veritabanı işlemlerinin ACID (Atomisite, Tutarlılık, İzolasyon, Dayanıklılık) özelliklerinden biridir. Yalıtım, işlem bütünlüğünün diğer kullanıcılar ve sistemler tarafından nasıl görülebileceğini belirler. Kaynak kilitleme yani eşzamanlılık kontrolü için kullanır, belirli bir noktada kaynağa yalnızca bir işlemin erişebildiğinden emin olun.
Kilitleme algısı: izolasyon seviyesi kilitlerin ne kadar süre tutulacağını belirler.
+---------------------------+-------------------+-------------+-------------+------------------------+
| Isolation Level Mode | Read | Insert | Update | Lock Scope |
+---------------------------+-------------------+-------------+-------------+------------------------+
| READ_UNCOMMITTED | uncommitted data | Allowed | Allowed | No Lock |
| READ_COMMITTED (Default) | committed data | Allowed | Allowed | Lock on Committed data |
| REPEATABLE_READ | committed data | Allowed | Not Allowed | Lock on block of table |
| SERIALIZABLE | committed data | Not Allowed | Not Allowed | Lock on full table |
+---------------------------+-------------------+-------------+-------------+------------------------+Okuma algısı: Aşağıdaki 3 ana sorun türü ortaya çıkar:
UPDATESbaşka bir tx'ten yapılan okumalar .INSERTSve / veya okurDELETESFarklı okuma türleriyle izolasyon seviyeleri:
+---------------------------+----------------+----------------------+----------------+
| Isolation Level Mode | Dirty reads | Non-repeatable reads | Phantoms reads |
+---------------------------+----------------+----------------------+----------------+
| READ_UNCOMMITTED | allows | allows | allows |
| READ_COMMITTED (Default) | prevents | allows | allows |
| REPEATABLE_READ | prevents | prevents | allows |
| SERIALIZABLE | prevents | prevents | prevents |
+---------------------------+----------------+----------------------+----------------+Read UncommitedGerçekten ACIDuyumlu olmadığı için neredeyse hiç kullanmak istemezsiniz . Read Commmitediyi bir varsayılan başlangıç yeridir. Repeatable Readmuhtemelen yalnızca raporlama, toplama veya toplama senaryolarında gereklidir. Postgres dahil olmak üzere birçok DB'nin Tekrarlanabilir Okuma'yı desteklemediğini, Serializablebunun yerine kullanmanız gerektiğini unutmayın . Serializablebaşka herhangi bir şeyden bağımsız olarak gerçekleşmesi gerektiğini bildiğiniz şeyler için yararlıdır; synchronizedJava'daki gibi düşünün . Serileştirilebilir REQUIRES_NEWyayılma ile el ele gider .
Kullandığım REQUIRESbütün fonksiyonlar için bu çalışma UPDATE veya iyi "hizmet" seviye fonksiyonlarının yanı SİL sorgular. Yalnızca SELECT'leri çalıştıran DAO düzeyi işlevler için SUPPORTS, önceden başlatılmışsa (yani bir hizmet işlevinden çağrılırsa) TX'e katılacak olanları kullanırım .
İşlem Yalıtımı ve İşlem Yayılımı her ne kadar ilgili olsa da açıkça iki farklı kavramdır. Her iki durumda da varsayılanlar, Bildirici işlem yönetimi veya Programlı işlem yönetimi kullanılarak istemci sınır bileşeninde özelleştirilir . Her bir izolasyon seviyesinin ve yayılma özelliklerinin detayları aşağıdaki referans bağlantılarında bulunabilir.
Veritabanına verilen iki veya daha fazla çalışan işlem / bağlantı için, bir işlemdeki sorgular tarafından yapılan değişikliklerin ne zaman ve ne zaman farklı bir işlemdeki sorguları etkilediği / görebildiği. Ayrıca, bu işlemdeki değişiklikleri diğer işlemlerden ayırmak için ne tür bir veritabanı kaydı kilitlemesinin kullanılacağı ile de ilgilidir. Bu genellikle işleme katılan veritabanı / kaynak tarafından uygulanır.
.
Herhangi bir talep / işlem için bir kurumsal uygulamada, işi yapmak için dahil olan birçok bileşen vardır. Bu bileşenlerden bazıları, ilgili bileşen ve alt bileşenlerinde kullanılacak bir işlemin sınırlarını (başlangıç / bitiş) işaretler. Bileşenlerin bu işlemsel sınırı için, İşlem Propogasyonu, ilgili bileşenin işleme katılıp katılmayacağını ve çağrılan bileşenin zaten oluşturulmuş / başlatılmış bir işlemi varsa veya başlatılmamışsa ne olacağını belirtir. Bu, Java EE İşlem Öznitelikleri ile aynıdır. Bu genellikle istemci işlem / bağlantı yöneticisi tarafından uygulanır.
Referans:
Ben çalıştırmak outerMethod, method_1ve method_2farklı yayılma modu ile.
Aşağıda farklı yayılma modu için çıktı bulunmaktadır.
Dış Yöntemi
@Transactional
@Override
public void outerMethod() {
customerProfileDAO.method_1();
iWorkflowDetailDao.method_2();
}Yöntem 1
@Transactional(propagation=Propagation.MANDATORY)
public void method_1() {
Session session = null;
try {
session = getSession();
Temp entity = new Temp(0l, "XXX");
session.save(entity);
System.out.println("Method - 1 Id "+entity.getId());
} finally {
if (session != null && session.isOpen()) {
}
}
}Method_2
@Transactional()
@Override
public void method_2() {
Session session = null;
try {
session = getSession();
Temp entity = new Temp(0l, "CCC");
session.save(entity);
int i = 1/0;
System.out.println("Method - 2 Id "+entity.getId());
} finally {
if (session != null && session.isOpen()) {
}
}
}Bunun için ekleyebiliriz:
@Transactional(readOnly = true)
public class Banking_CustomerService implements CustomerService {
public Customer getDetail(String customername) {
// do something
}
// these settings have precedence for this method
@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void updateCustomer(Customer customer) {
// do something
}
}Bunun gibi kullanabilirsiniz:
@Transactional(propagation = Propagation.REQUIRES_NEW)
public EventMessage<ModificaOperativitaRapporto> activate(EventMessage<ModificaOperativitaRapporto> eventMessage) {
//here some transaction related code
}Bu şeyi de kullanabilirsiniz:
public interface TransactionStatus extends SavepointManager {
boolean isNewTransaction();
boolean hasSavepoint();
void setRollbackOnly();
boolean isRollbackOnly();
void flush();
boolean isCompleted();
}