Javisté a databáze - základní chyby

Na školení jsem všem implicitně vynadal, že nikdo pořádně neumí používat ani JDBC, ale chtějí (dobře) používat JPA nebo JTA. A co teprve, aby rozuměli trochu tomu, co jejich zacházení způsobí na databázovém serveru ...
Pak se diví, že jim to celé padá na hubu - typicky začnou optimalizovat SQL, ale marně. Jen málokoho napadne, že databázi dávají kapky - pro každý váš požadavek databáze alokuje nějaké zdroje v operační paměti, přidělí vlákno, příkaz zabere nějaké místo na file systému, a databáze čeká až na signál od vás, že už jste hotoví.
Tož si překontrolujte, jestli si databázi nepřetěžujete ...

• zavíráním statementů
  
  • kolikrát za sebou generujete stejný prepared statement?
    
  • nezavíráním statementů
    
  • jak dlouho má db držet statement?
    
  • kolik stejných prepared statementů držíte najednou?
    
  • poslední pomoc: omezit počet použití konexe z poolu, pak jí AS nuceně zavře a otevře novou (Payara)
    

• nezavíráním result setů
  
  • jak dlouho má db držet nalezená data, kurzor?
    
  • kolik dat to je?
    
  • fetch size
    

• zbytečně dlouhými transakcemi se spoustou změn
  
  • víte, co se děje v databázi?
    
  • víte, že i zdroje databáze jsou omezené?
    

• nemazáním dočasných tabulek, vytvořených v poolovaných konexích
  
  • je to v podstatě leak, zapomenutá data pak můžou být náhodně nalezena jiným dotazem, čili hypoteticky to může být i bezpečnostní díra.
    

• nadměrným využíváním indexů nebo naopak jejich absencí
  
  • každé vložení dat způsobí změnu v indexech
    
  • databáze jsou různě chytré/hloupé při optimalizacích
    
  • indexy pomáhají při čtení
    
  • indexy škodí při zápisu
    
  • někdy se hodí replikace db tak, aby db pro vyhledávání byla důsledněji indexovaná než ta pro zápis
    

• chybným nastavením JDBC poolu
  
  • default lock timeout
    
  • velikosti bufferů
    
  • různé optimalizace
    
  • rozdělení datových zdrojů podle použití (exporty vs. CRUD)
    

• chybným nastavením:
  
  • stmt.setQueryTimeout
    
  • stmt.setMaxRows
    
  • stmt.setFetchSize
    
  • conn.setTransactionIsolation
    
  • conn.setResultSetConcurrency
    
  • conn.setHoldability
    

JPA samozřejmě k relační db přistupují přes jdbc, ale pozor!

• JDBC transakce není nutně pod JPA transakcí a už vůbec nejsou svázané 1:1
  
• JPA transakce není JTA transakce
  

• můžou. Je to záležitost nastavení "persistence unit" a také nastavení hintů (viz Query.setHint)
  

• EntityManager.unwrap(Connection.class) znamená spuštění JDBC transakce a svázání 1:1 JDBC konexe a JPA manažera se vším, co to obnáší.
  

JTA se pak řídí hlavně anotacemi, ale pozor pozor!!!

• pokud si nedáte pozor, můžete si připravit neskutečné magické transakční peklo
  

• „requires“ je dobrý default
  

• „requires new“ se někdy hodí, ale … uvědomte si, co to znamená!
  

• některé posloupnosti těchto hodnot dokážou naprosto šílené věci – s kolika JPA kontexty a JDBC konexemi nakonec opravdu pracujete?
  

Jste programátoři, vědci, ne pistolníci z televizního divokého západu. Na riskování není čas, musíte přesně vědět, co děláte ;-)

SGES2 a nové JAX-WS a JPA2

Pěkně to tu mají napsané, pěkně. A vždycky to má háček. No, našel jsem trochu jinou cestičku. Java si vždycky hledá takové properties soubory, ve kterých má napsanou default implemetaci nějakého API.
Ale asi bych měl začít od začátku - problém byl takový: Naučili jsme SGES2.1.1 novým kouskům tak, že jsme v adresáři lib udělali pár změn (AS, ne domény!):

1. Souborům toplink-essentials-agent.jar, webservices-rt.jar, webservices-tools.jar, endorsed/activation.jar a endorsed/webservices-api.jar jsme přihodili příponu .Orig - to aby je aplikáč nenačítal, ale abychom měli nějakou stopu po tom, že jsme tu prováděli "psí kusy".
   Ještě malá poznámka - toplink-essentials.jar nepřejmenováváme, jelikož ho potřebuje interní ejb timer a nám konec konců nevadí, protože JPA providera si vybírá každá aplikace dle svého gusta v persistence.xml.
   

   cd ${appserv.home}
   mv ./lib/toplink-essentials-agent.jar ./lib/toplink-essentials-agent.jar.Orig
   mv ./lib/webservices-rt.jar ./lib/webservices-rt.jar.Orig
   mv ./lib/webservices-tools.jar ./lib/webservices-tools.jar.Orig
   mv ./lib/endorsed/activation.jar ./lib/endorsed/activation.jar.Orig
   mv ./lib/endorsed/webservices-api.jar ./lib/endorsed/webservices-api.jar.Orig
   

2. Do adresáře lib nakopírujeme nové soubory. K dostání jsou obvykle na stránkách autorů nebo v různých maven repositories. Co přesně musíte stáhnout se může lišit podle toho, jak moc se vzdálíte od staré implementace, ale každopádně bude třeba pokrýt to, co plnily přejmenované knihovny. Náš seznam je následující - Javě je jedno, jak se soubory jmenují, podstatné je, že mají příponu .jar, tudíž jsme ponechali i čísla verzí:
   

   webservices-rt-2.2.jar
   webservices-tools-2.2.jar
   eclipselink-2.3.2.jar
   endorsed/javax.persistence-2.0.3.jar
   endorsed/webservices-api-2.2.jar

3. To jsem napsal v podstatě totéž, co mají na odkazu v začátku. Jenže při prvním nasazení aplikace zjistíte, že pokud v persistence.xml vyplníte element <class>, aplikace vám neprojde validací!!!
   Háček je totiž v tom, že AS se řídí různými properties, poházenými po classpath v knihovnách v adresáři META-INF/services. Ty mu říkají "default" implementace API, které on sám použije; název souboru je v našem případě javax.persistence.spi.PersistenceProvider.properties
   Protože jsme ale nechali na classpath TopLink, má AS na výběr mezi TopLinkem a EclipseLinkem. Který zvolí, záleží na tom, který soubor najde dřív - čili nejspíš TopLink, protože při startu pravděpodobně bude nahazovat EjbTimer.
4. Slova "pravděpodobně" a "nejspíš" se mi nelíbí, ale řešení je snadné - do aplikace si ten property soubor přidejte taky :-)
   A potom zapomeňte na pokusy dávat knihovny na classpath-prefix, což navrhují v onom odkazu - zkoušel jsem to, nefunguje to.

A ještě troška deziluze - zapomeňte na to, že vám SGES2 kdy bude dělat JEE6 server. Takovou certifikací neprošel a nikdy neprojde, prostě taková funkcionalita kontejneru v něm není. Nikdy nebude umět pracovat s anotacemi podle JEE6, prostě protože se musí pevně držet JEE5.
JEE5 Aplikace sice bude bezpečně fungovat na JEE6 serveru, ale to pořád neznamená, že vnitřně JEE6 server obsahuje JEE5 server. Toto nejsou Windows!
Důvody zpětné kompatibility jsou jen anotace a API - vaše JEE5 aplikace jimi deklaruje nějaké požadavky (na zdroje, transakce, atd.), ale vůbec tím neříká, jak je server má splnit (pokud ovšem nepoužívá "deprecated" atributy anotací nebo něco neloví přes InitialContext).
Zkrátka, pokud chcete JEE6, musíte přejít na nějaký certifikovaný  JEE6 aplikáč. Třeba Glassfish3, ať nechodíte daleko.

Tenhle návod vedl jen k tomu, abychom mohli použít např. Criteria API, nové JAX-WS a pár dalších novinek.

EDIT: Jeden příklad toho, co nebude fungovat - SGES používá tuto implementaci EntityManager wrapperu - ano, tušíte správně, metodu z JPA2 díky němu nevyvoláte, čili například nemůžete použít TypedQuery.