Zobrazují se příspěvky se štítkemjPower8. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemjPower8. Zobrazit všechny příspěvky

středa 2. dubna 2014

Řízení transakcí přes různé DAO implementace

Na startu projektu jdemenato.cz jsme DAO vrstvu implementovali přes JPA/Hibernate - standardně dle návodů.

V produkčním režimu, kde nám neustále roste počet uživatelů, jsme s tímto naivním řešením vydrželi jen několik měsíců. Kritické dotazy, které nejvíce vytěžovaly databázi,  jsem přepsali přes Criteria API na "lepší" SQL dotazy.

Po dalších měsících produkčního života nás zákaznické požadavky přinutili některé SQL dotazy psát ručně. Nejprimitivnější jsme zrealizovali přes Hibernate native SQL ale u složitějších jsme šáhli na JdbcTemplate a později k MyBatis.

To ovšem nastolilo problém s řízením databázových transakcí, jejichž součástí je více DAO technologií.

Ukázalo se, že na podobné případy chlapci ve springu pamatovali a stačilo vyměnit HibernateTransacionManager za DataSourceTransactionManager.

Tímto způsobem je DataSource "nejmenším společním jmenovatelem" spojující DAOs implementované přes Hibernate, MyBatis i JdbcTemplate.

Aby si AnnotationSessionFactoryBean nevytvořila svůj vlastní transakční manager, je nutné nastavit ji property useTransactionAwareDataSource=true.

        
<bean name="sessionFactory" 
  class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
  <property name="dataSource" ref="dataSource"/>       
  <property name="useTransactionAwareDataSource" value="true"/>
</bean>
<bean id="sqlSessionFactory" 
         class="org.mybatis.spring.SqlSessionFactoryBean">
  <property name="dataSource" ref="dataSource"/>
  <property name="configLocation" value="classpath:/META-INF/mybatis/myBatis-configuration.xml"/>
</bean>

pondělí 14. října 2013

Logování pomalých dotazů v PostgreSQL

Na produkčním prostředí jsem se snažil zjistit, které dotazy databázi nejvíce vytěžují.

Mile mě překvapilo, jak mocný je v tomto ohledu PostgreSQL.

Jednoduché logování dotazů, jejichž čas zpracování trvá více jak monitorovaný čas mě umožnil identifikovat dotazy, o kterých jsem ani netušil, že by mohli dělat problém.

Stačí v postgresql.conf zapnout magický přepínač log_min_duration_statement, který je defaultně vypnutý.

Pokud ho nastavím takto
log_min_duration_statement=100
tak mi do logu databáze zapíše dotazy, které trvají více jak 100ms.
Pak už přichází ke slovu klasický explain a refaktoring.

pondělí 5. listopadu 2012

Continuous delivery v jPower8


Náš produkt nasazujeme produkci každé dva týdny. Máme tak nastavený sprint cyklus.

 Celý proces je (skoro) plně automatický.


Zdrojáky verzujeme v svn (migraci na git plánujeme).

Stabilitu buildu udržuje TeamCity, které

  • provádí unit testy,
  • spouští seleniové (integrační) testy,
  • nasazuje na testovací prostředí a
  • provádí statickou analýzu kódu.

Doba od commitu do nasazení na test je cca 15 minut.

Pro upečení stabilního verze používáme maven-release-plugin, který se postará o to, že zvedne verzi ve všech pomech, otaguje verzi v svn a uloží upečený build do artifactory. To vše se děje jedním stiskem tlačítka na TeamCity.

Posledním krokem je samotné nasazení waru na produkční prostředí. To dělám kvůli svému pocitu důležitosti ještě stále ručně (a protože nechci, aby TeamCity mělo na produkci přístup).

Samostatnou kapitolou je aplikace migračního databázového skriptu. Ještě donedávna jsme ji prováděli ručně, což sebou neslo riziko lidské chyby a hlavně velkého opruzu.

Pokud je například potřeba přejmenovat sloupec do tabulky, přidat index, změnit constraint, vývojář commitnul migrační sql sript do svn. Dále musel změnu aplikovat u sebe lokálně minimálně na dvou databázích - jedna pro unit testy a druhá pro lokální vývoj. Dále musel změnu provést na testovacím prostředí na dalších třech databázích. Ostatní vývojáři si také museli tuto změnu aplikovat u sebe lokálně. No prostě opruz až na půdu.

Tuto příjemnou činnost jsme hodili na framework flyway. Má přesně takovou složitost, jakou jsme byli ochotni akceptovat. Do databáze přidal jednu tabulku, ze které je naprosto zřejmé, které migrační skripty už v databázi jsou aplikované. Vše je plně automatické a v režii spring beany. Jednoduché jako facka.

A jak jste se zaváděním continuous delivery vy?

úterý 23. října 2012

Kradu jako umělec

Na iTunes jsem narazil na další pecku nakladatelství Melvil.

Jde o brutálně zjednodušenný výtah rad k odblokování tvůrčího ducha.

Jednu radu jsem hned aplikoval, vytáhl blok, pastelky a design rezervačního formuláře pro náš produkt jdemenato jsem vysmrkl ručně.

Vykradl (nechal se inspirovat) jsem kalendář Googlu, iCalu a Outlooku. Konkurenční systémy jsem ani vykrást nemohl, neb opakující se rezervace vůbec nepodporují.

Pastelky, ořezávátko a papíry jsou už nedílnou součástí mého analogového stolu.

A co vy? Pamatujete si ještě ze školky co jsou to pastelky?

úterý 18. října 2011

Validace vstupních parametrů metod.

Všechny vstupní parametry metod je vhodné validovat na jejich korektnost dříve než se s nimi začne pracovat.
V 90% případů mi stačí zkontrolovat, že vstupní parametr není null.
Joshua Bloch radí vyhodit NullPointerException, ale já, a troufám si tvrdit že i velká část java komunity, preferuje IllegalArgumentException.
Kód by mohl vypadat třeba takto
    public void foo(final String request) {
        if (request == null) {
            throw new IllegalArgumentException("Parameter 'request' can't be null.");
        }
    }
Protože nejsem na světě sám, co potřebuje validovat vstupní parametry, existuje spousta knihoven, které lze pro tyto účely využít (psát vlastní validační knihovnu považuji jen za zvyšování chaosu ve vesmíru).
První možností je třída org.apache.commons.lang.Validate z knihovny Apache Commons Lang.
    public void foo(final String request) {
        Validate.notNull(request, "Parameter 'request' can't be null.");     
    }
Místo původních třech řádků jen jeden. Na skoro všech projektech ale používám i Spring, tak proč nepoužít třídu org.springframework.util.Assert, která je hodně podobná org.apache.commons.lang.Validate?
    public void foo(final String request) {
        Assert.notNull(request, "Parameter 'request' can't be null.");
    }
Samotní autoři nedoporučují použít tuto třídu! Citace z javadocu:
Mainly for internal use within the framework; consider Jakarta's Commons Lang >= 2.0 for a more comprehensive suite of assertion utilities.
Další možnou variantou je knihovna Guava.
    public void foo(final String request) {
        Preconditions.checkNotNull(request, "Parameter 'request' can't be null.");
    }
Na té se mi ale nelíbí, že vyhazuje NullPointerException a varianta checkArgument, která vyhazuje IllegalArgumentException má vytaženou podmínku ven z metody, čímž se kontrola lehce komplikuje.
    public void foo(final String request) {
        Preconditions.checkArgument(request != null, "Parameter 'request' can't be null.");
    }
Já osobně zůstanu u třídy Validate. Jak validujete parametry metod vy?

úterý 10. května 2011

YouTrack v jPower8

Při spouštění firmy jsme potřebovali vyřešit problém issue trackingu. Přestože je v open source komunitě spousta řešení, šáhli jsme nakonec po komerčním řešení.

Co nás přesvědčilo?
  • Webové rozhraní - dostupnost i z domova i z práce.
  • Extrémně jednoduché ovládání – ostatně jako u všech produktů jetbrains.
  • Integrace na IntelliJ IDEA – umí dokonce i Jíru nebo PivotalTracker.
  • Integrace do TeamCity – u každého issue vidíme, v jakých buildech se na úkolu pracovalo.
  • Integrace na firemní LDAP.
  • Neomezený počet projektů i uživatelů.
  • Detailní možnosti nastavení přístupových práv.
  • Restové rozhraní pro import i export dat.
  • Přidávání custom políček a tagů.
  • Rychlost vyhledávání.

Interně používáme youtrack na řízení všech úkolů, které ve firmě řešíme. Dokonce naši zákazníci zapisují své připomínky a návrhy také do youtracku, kde průběžně vidí, jak se na nich pracuje. Šetříme tak čas svůj i zákazníka – prostě win-win strategie.

Používáme youtrack i jako vykazovací systém, ale o tom až příště.