Sep 07
Local Transaction
Önceki bölümde anlattığımız gibi Local Transaction’larda kullanıcı connection’ları yönetir, transaction’ları değil. Örnek vermek gerekirse;
// herhangi bir datasource'dan connection
// aldığımızı düşünelim
Connection conn = ds.getConnection();
// autoCommit'i devre dışı bırakarak transaction
// yönetimini bizim elimize geçiyor
conn.setAutoCommit(false);
Statement stmt = conn.createStatement();
String sql = "update user set username = 'javaci' where id = 1";
try {
stmt.executeUpdate(sql);
conn.commit();
} catch(Exception exc) {
conn.rollback();
} finally {
stmt.close();
conn.close();
}
Yukarıda gördüğünüz kodda setAutoCommit(false) komutu ile her sql cümleciği için ayrı bir commit yapmadan, sadece conn.commit() satırını görünce toplu bir commit yapılacaktır. Böyle yapmamız hem hız açısından hem de data güvenirliliği açısından önemlidir.
// herhangi bir datasource'dan connection
// aldığımızı düşünelim
Connection conn = ds.getConnection();
// autoCommit default değeri true
conn.setAutoCommit(true);
Statement stmt = conn.createStatement();
String sql1 = "update user set username = 'javaci' where id = 1";
String sql2 = "update user set password = 'gizli' where id = 1";
try {
stmt.executeUpdate(sql1);
stmt.executeUpdate(sql2);
} catch(Exception exc) {
} finally {
stmt.close();
conn.close();
}
Yukarıdaki kod ACID kuralına uymayacaktır. sql1 calışıp commit edilebilir ve sql2 commit edilmeyebilir. Çünkü setAutoCommit(true) (default değeri true) yapılmıştır ve her sql satırı ayrı ayrı commit edildiğinden geri almak (rollback) mümkün olmayacaktır.
Local Transaction Modeli küçük uygulamalar için kullanılabilir bir transaction modelidir. Fakat daha karmaşık yapılara geçildiğinde bize dezavantajlarını gösterecektir. Mesela farkettiyseniz geliştirici aynı zamanda commit ve rollback gibi transaction işlemlerini de düşünmeli ve kodlamalıdır. Bu ayrıca geliştiriciye bir yük olmaktadır. Diğer bir problem ise Local Transaction Model aynı anda birden fazla olamazlar, Distributed Transaction yapamazsınız.
yazan Erol KOCAMAN
\\ tags: transaction, veritabanı
Aug 25
Local Transaction
Günümüzde birçok Java ile geliştirilmiş büyük ölçekli projeler bulunmakta. Bunların bazıları web tabanlı, birçoğu ise daha karmaşık bir yapıya sahip olan n-tiered uygulamalardır. Bu karmaşık yapıya sahip olan yazılımların karşılaştıkları en büyük problemlerden biri de data uyuşmazlığıdır. Yani aslında müşterinin hesabından para çekilmiştir fakat müşteriye ürünü yollamak için veritabanında bir kayıt tutulmamıştır. Bu gibi problemlerin asıl kaynağı transaction yönetim stratejilerinin yanlış olmasından kaynaklanmaktadır.
Çoğu zaman biz geliştiriciler transaction yönetimini önemsemeyip bu işlemi veritabanına bırakırız. Fakat bu her zaman doğru bir seçim olmayabilir. Eğer büyük ölçekli bir Java projesi geliştiriliyor ise önceden her bir işlemin transaction stratejisi çıkarılmalıdır.
Transaction Modelleri
Java’da 3 tane transaction modeli bulunmaktadır. Bunlar;
1. Local Transaction Modeli: Aslında transaction’ı yöneten bir kütüphane yoktur. Transaction veritabanı driver’ları tarafından kontrol edilir. Mesela bir veritabanı için Local Transaction DBMS(Database Management System) tarafından yönetilir. Aslında kullanıcı bu transaction modeli ile transaction’ları değil connection’ları yönetir.
2. Programmatic Transaction Model: Burada transaction bir Java kütüphanesi tarafından yönetilir. Buna JTA(Java Transaction API) denir. Bu modelde kullanıcı transaction’ları yönetebilmek için kod yazar.
Javax.transaction.UserTransaction interface üzerinden begin ve commit kodları arasındaki tüm veritabanı işlemleri bir transaction olarak işlenir. Rollback methodu ile de transaction rollback edilir.
3. Declarative Transaction Model: Bu model Container-Managed Transaction(CMT) olarak da bilinir. Bu modelle transaction yönetimi ayrı bir birime iletilmiştir. Geliştirici olarak biz sadece transaction’ın ne zaman rollback yapması gerektiğini söyleriz. Geri kalan tüm işlemler container içerisinde halledilir. Bu model daha çok EJB’lerde kullanılır.
ACID (Atomicity, Consistency, Isolation, Durability)
ACID kavramı veri tutarlılığı ve güvenirliliği açısından önem taşımaktadır. Eğer yapılan kodlama ACID kavramını kırabiliyorsa veri tutarlılığı olamaz.
Atomicity: Bir transaction içerisindeki işlemlerin ya hepsi yapılır ya da hiçbiri yapılmaz
Consistency: Veritabanı içerisinde bir takım kısıtlamalar tanımlanmış ise bu kısıtlamalara aykırı veri eklenmeye çalışıldığında transaction iptal edilir.
Isolation: Transaction çalışırken veriler üzerinde yapılan değişikliklerin dışarıdan ne kadar görünebilir olduğuyla ilgili bir kavramdır.
Durability: Transaction tamamlandığı zaman verinin artık veritabanında olduğunu garantilemesidir. Transaction tamamlandıktan sonra herhangi bir hata transaction içerisindeki veriyi etkileyemez.
JTA vs JTS
JTA(Java Transaction API) aslında transactionları yönetmek için gerekli tanımlamaları yapar. JTS(Java Transaction Service) ise JTA kullanarak bu tanımlamaları uygular. Buna örnek olarak Jboss Transaction Service verilebilir.
UserTransaction interface JTA içerisinde yer almaktadır. Bu interface 4 method içermektedir. Bunlar;
Javax.transaction.UserTransaction.begin()
Yeni bir transaction başlatır ve o anki thread’e transaction’ı atar. Eğer thread önceden bir transaction’a sahip ise NotSupportedException atar.
Javax.transaction.UserTransaction.Commit()
O anki thread üzerindeki transaction’ı commit eder ve sonlandırır.
Javax.transaction.UserTransaction.Rollback()
O anki thread üzerindeki transaction’ı sonlandırır.
Javax.transaction.UserTransaction.getStatus()
O anki transaction durumunu javax.transaction.Status interface’i olarak döner.
yazan Erol KOCAMAN
\\ tags: transaction, veritabanı
Son Yorumlar