JAXB: döngüsel bağları XML’de anahtarlma (cyclic reference problem)
Döngüsel Bağ (Cyclic Reference) nedir?
Baba-Cocuk iliskisine sahip siniflarda, bir baba sahip oldugu cocuklarina referans tutarken, cocuk da babasina referans tuttugu durumda döngüsel bağ problemi ortaya cikar. Derleyiciler bu durumu anlayip döngüyü bir sekilde kirabilmektedirler. Asil sorun bu iliskideki nesnelerin XML’e bind edilmesi sirasinda ortaya cikabiliyor. JAXB standardinda bu sorunu ele alma yontemleri bu baglantida gosteriliyor : https://jaxb.dev.java.net/guide/Mapping_cyclic_references_to_XML.html
Quartz: Job Scheduling
Quartz, iş sıralama(job scheduling) diye tabir ettigimiz belli zamanlarda calisacak belli gorevleri yoneten, bu gorevlerin yasam döngüsünü düzenleyen java teknolojisi. JEE uygulamalarina entegrasyonu da mumkun. Gun sonunda kredi borcunu odemeyenlere SMS gondermek, 2 saatte bir veritabaninin yedegini almak vs. istedigimizde Quartz i uygulamamiza ekleyebiliriz. Quartz ile ilgili daha ayrintili bilgi icin:
soapUI & Netbeans 6.5 ile Web Servis testi
Netbeans, JAX-WS uzerinde web servis gerceklestirimi icin kolayliklar sunmasina ragmen, olusturulan web servislerin test edilmesi adina butunlesik gelen bir araci bulunmamaktadir. Web servisleri test etmek icin soapUI ‘nin Netbeans eklentisini kullanabilirsiniz.
GET vs POST – Kullanim Durumlari
HTML belirtim belgelerinde yazilana gore POST ve GET arasindaki en temel fark. GET metodu kullanildiginda bir formun
verileri URL bilgisi icerisinde kodlanmasi, POST metodunda istemin mesaj kisminda tutularak gonderilmesidir.
Belirtim ayni zamanda bahsi gecen bu metodlarin kullanim durumlari icin de bir oneri getirmektedir. Oneriye gore bilgi getirme islemleri icin(veri okuma) GET kullanilmali, bunun disindaki islemler icin ise (guncelleme, ekleme, siparis verme, e-posta gonderme vb.) POST metodu kullanilabilir.
Yukaridaki ifadeye gore, form gonderme islemimiz şayet sadece kullanicin ekraninda bir degisiklik yaratacaksa, baska bir deyisle, veritabaninda ya da diger kaynaklarda herhangi bir degisiklige sebep olmayacaksa GET kullaniriz. Ornek olarak, bir kutuphane otomasyonunda, form icerisinde girilen Yazar’in kitaplarinin getirilmesi işlemi veritabanimizda sadece okuma işlemi yapiyorsa GET kullanabiliriz.
Peki neden boyle bir ayrima gidilmis? POST yerine GET, GET yerine POST kullanmak mumkun iken farkli kullanim durumlari olusturulmus? Aslinda yine ornek bir senaryodan yola cikalim ve bir su dagitim firmasinin sitesinden 1 tane su siparis verdigimizi dusunelim. Sipariş onaylanmiş ve su firmasi adresimize bir adet suyu gonderiyorken, tarayicinin geri tusuna basip karsimiza gelen siparis formunu hatayla tekrar submit ettigimizi varsayalim. Bu durumda tarayicinin bize bir uyari mesaji sundugunu goruruz cogu zaman.Bu mesajda bize “POST isteminin yeniden gondermek istediginizden emin misiniz?” benzeri bir soru yoneltir.”Evet” deyip devam edersek yeni siparis gonderilmis olacak.Obur taraftan durumun farkinda olan bir kullanici “hayir” diyerek siparisin gonderilmesini iptal edebilir.
Tarayicinin yaptigi iş aslinda, POST istemlerinde kullaniciyi uyaran, hatali islemlere sebep olacak kullanimlardan kullaniciyi haberdar etmek adina yukarida bahsedilen mekanizmayi kullanmaktir. Ayni mekanizma GET icin gecerli degildir. Cunku en basta bahsettigim gibi, GET dis kaynaklarda bir degisiklige yol acmayacak istemler olarak ele alindigindan kullaniciyi uyarmaya gerek gorulmez. Şayet su firmasinin webmasteri POST yerine GET kullanmis olsaydi hicbir uyari gormeden yukaridaki senaryoda ust uste su siparisi verecektik.
POST ve GET arasindaki teknik farklara goz atacak olursak da:
POST
1. Varsayilan oılarak veriler önbellekte(cache) tutulmaz.Veriler her zaman web sunucusundan cekilir.
2. Veri uzunlugu ile ilgili bir kisitlama yoktur. Daha dogrusu web sunucusuna baglidir.
3. Karakter kodlamasi application/x-www-form-urlencoded olarak kolayca yapilabilir.
4. CGI sunucularinda, gelen parametreler STDIN kanalindan okunur.
GET
1.Veriler önbellekte saklanir.
2.Tarayiciya gore degisen maksimum URL uzunluguna gore gonderilebilecek veri uzunlugu bellidir.
3.CGI sunucularda, gelen parametreler QUERY_STRING degiskeni üzerinden okunur.
Özet olarak
- Dış kaynaklarda degisiklige yol acacak durumlarda(veritabaninda degisiklik vb.) POST kullanmali.
- Veri uzunlugu fazla ise POST kullanmali
- Verilerin önbellekte saklanmasini istiyorsaniz GET kullanmali.
- Guvenlik soz konusu ise(Kredi karti numarasi vs.) ve önbellekte durmasini istemiyorsaniz POST kullanmali
- Parametrelerin URL kisminda gorunmesini istemiyorsaniz POST kullanmali
Son olarak, genelde GET metodunun POST metoduna gore daha hizli calistigini(tarayici faktoru vardir) ve yukaridaki kullanim durumlarina gore POST gerektirmeyecek durumlarda GET kullanmanın performansi arttirdigini soylemek istiyorum.
Hibernate ve Transaction Yonetimi
Veritabani uygulamalarinda, CRUD(Create Update Delete) işlemleri yaygın olarak kullanılır. Transaction veritabanindaki verilerin dogru ve diger verilerle tutarli olmasini saglamak icin kullanilan bir yontemdir. Kısacasi “işlem grubu” olarak tanımlanabilir. Bu işlem grubunu oluşturan işlemler veritabaninda yazma/okuma/guncelleme islemleri yapan işlemlerdir genelde.
Transaction temelde begin, commit ve rollback operasyonlarini yapar. Begin ile “birazdan veritabani islemleri yapacagim haberin olsun” diyoruz, Transaction’da “tamam o zaman yaptigin islemleri ben aklima yaziyorum, ama veritabanina hemen yansitmayacam ancak ve ancak zamani gelince yaparim o işi” der.
Transaction begin ile baslatildiktan sonra ve veritabani işlemlerini gerceklestirdikten sonra commit ile “İşlemlerimi hallettim, şimdilik bi işim kalmadi, bu aklina aldigin degisiklikleri artik veritabanina yansit” diyoruz. Transaction da “tamamdir patron” der ve veritabani kayitlari uzerinde yaptigimiz degisiklikler ancak o zaman gercekten yansir. Peki yaptigimiz veritabani islemlerinde biri hataya neden olursa ne olur? İşte o zaman transaction rollback dedigimiz “geri alma” işlemini yaparak aklina aldigi işlemleri iptal eder ve veritabanina hic bir degisiklik yansimamis olur.
Bunun onemi nedir peki? Kritik bir işlem dizisi düşünelim mesela bir banka işlemi. Bu işlem dizisinin adi P olsun ve A,B, C işlemlerinden olussun. Bir transaction baslatilip, sirasiyla A ve B işlemlerini basarili bir sekilde yaptigimizi ancak C isleminde onemli bir hata olustugunu dusunelim. Boyle bir senaryoda P islem dizisinin tümden basarisiz olmasi beklenir ve A,B işlemlerinin sonuclarinin iptal edilmesi, urettikleri degisikliklerin veritabanina yansimamasi istenir. Istedigimiz aslinda transaction’ın rollback ozelligi.
Transaction’ı basit duzeyde ifade ettikten sonra bunu hibernate ile nasil kullanilacagini soylemek de sira. Hibernate bize 3 şekil Transaction Yonetimi sunar. Bunlarin ayrintisini ve konfigurasyonun nasil yapildigini ogrenmek icin buradan okuyabilirsiniz. Ben sadece programci gozuyle bu yontemleri ne zaman ve nasil kullanmamiz gerektiginden bahsedecegim.
1. JDBC Transaction Yonetimi
JDBC Transaction Yonetimi varsayilan ele alma bicimidir. Veritabani duzeyinde ele alinir. Ancak hibernate bize JDBC API’leri ile ugrasmaktansa Session nesnesi ile sarmaladigi transaction nesnesini kullanmamiza izin verir. Bu transaction nesnesini kullanabilmek icin mutlaka bir tane Hibernate Session nesnemiz olmalidir.
try {
//Transaction, Hibernate session nesnesi araciligiyla baslatilir
factory.getCurrentSession().beginTransaction();
// İslem dizisi
factory.getCurrentSession().load(...);
factory.getCurrentSession().persist(...);
//Transaction commit edilir, degisiklikler onaylanır
factory.getCurrentSession().getTransaction().commit();
}
catch (RuntimeException e) {
//Hata durumunda rollback yapilir
factory.getCurrentSession().getTransaction().rollback();
throw e;
}
2. JTA Transaction Yonetimi
Java Transaction API, bir java standardidir. JTA ile ilgili bilmeniz gereken en onemli unsur, dagitik birden cok veritabaniyla uygulamanizin baglantisi varsa JTA kullanmanizin gerekliligidir. Programlama olarak JDBC yonteminden farki transaction nesnesinin JNDI yontemile elde edilmesi, yani bunun icin Hibernate Session nesnesine ihtiyac duymamasidir. Ancak arka planda current session ile JTA transaction’i otomatik olarak birbirine baglanmaktadir.
try {
UserTransaction tx = (UserTransaction)new InitialContext()
.lookup("java:comp/UserTransaction");
tx.begin();
factory.getCurrentSession().load(...);
factory.getCurrentSession().persist(...);
tx.commit();
}
catch (RuntimeException e) {
tx.rollback();
throw e;
}
3. CMT/EJB Transaction Yonetimi
EJB3 dependency injection ile Transaction yonetiminin kodlanmasiyla ilgilenmek istemiyor, bunun arka planda otomatik olarak yapilmasini istiyorsaniz bu yontemi kullanabilirsiniz. Boyle bir durumda asagidaki gibi bir methodun cagrilmasiyla Transaction yaratilmis, sonlanip geri donmesiyle otomatik olarak sonlandirilmistir. Hicbir sekilde Transaction nesnesine mudahale etme imkaniniz bulunmuyor. begin, commit,rollback methodlarini cagirmaniz durumunuda IllegalStateException alirsiniz
@TransactionAttribute(TransactionAttributeType.REQUIRED) public void doSomeWork() { // Do some work factory.getCurrentSession().load(...); factory.getCurrentSession().persist(...); }
Glassfish Hata:ADM5801:Admin server channel creation failed.
Windows XP uzerinde Netbeans 6.7 ile butunlesik gelen glassfish v2′nin baslatilmasi esnasinda alinan bu hata gercekten bir sure bas agritici olmustu benim icin. Hata arastirildiginda genelde XP ortam degiskenlerinden SystemRoot degiskeninin eklenmesi ve sistemdeki Windows dizininin adresinin deger olarak verilmesi gerektiginden bahsediliyor. Ornegin C:\WINDOWS seklinde. Kucuk/Buyuk harf duyarli oldugu icin adresi birebir vermeye ozen gostermelisiniz.
SystemRoot degiskenini ayarlamama ragmen ayni hatayi almaya devam ediyordum. Ingilizce olan XP sistemimde Region/language ayarlarini asagidaki gibi Turkce’den Ingilizceye cevirdikten ve Netbeans’i yeniden baslattiktan sonra glassfish normal bir sekilde baslamisti.Sonuc olarak Glassfish ten bir bug daha 
Dil ayarlarini degistirme- SC
bir yorum yazın