Názory k článku
JBoss: EJB a transakce

na těchto proměnných není vůbec nic speciálního. ThreadLocal je třída jako každá jiná a pro uložení hodnot používá zřejmě něco jako Map<Thread,Object>.

No to je sice možné, že se data z těchto proměnných čtou běžným způsobem, ale speciální je na tom čtení to, že se data vážou k vláknu a jsou v rámci něj globální.

Normální jsou totiž při čtení proměnných dva způsoby:
1) lokální data - čtou se z předaných parametrů metody (v jediném vlákně)
2) globální data - jsou sdílená mezi všemi vlákny

Ukládání dat k jednotlivému vláknu je speciální tím, že je mohou číst všechny metody, ale platí jen v rámci jediného vlákna. To je v jazyku Java něco "extra".

Jste vedle jak ta jedle. Podívejte se na Java Language Specification a najděte mi ten váš extra objekt. Instance třídy ThreadLocal jsou objekty jako každé jiné a nemají žádná specifika a už vůbec není pravda že objekt typu ThreadLocal má platnost pouze v rámci jediného vlákna. Pokud si projdete zdrojové kódy tříd Thread a ThreadLocal, zjistíte ThreadLocal je vcelku jednoduchá třída (až na některé složitosti kvůli garbage collection).

Aby jste mohl ThredLocal používat, musíte vytvořit instanci. Tuto instanci musíte zpřístupní všem třídám, které ji hodlají využívat. Taková instance se vytvoří na Heapu a heap je zdílený všemi vlákny. Z kteréhokoli vlákna můžete zavolat hashCode a vždy dostanete tu samou hodnotu.

Asi největší "specialitou" je nativní metoda Thread.currentThread() bez které by tento mechanismus ThreadLocal nefungoval.

Máte pravdu v tom, že instance ThredLocal do sebe umí uložit objekt a svázat s aktuálním vláknem. Ale jak už jsem psal v minulém příspěvku to samé lze provést mapou Map<Thread,Object>. Jednoduchá implementace by mohla vypadat takto:

public class ThreadLocal<T> {
    private Map<Thread,T> map = new HashMap<Thread,T>();

    public void set(T obj) {
        this.map.put(Thread.currentThread(), obj);
    }

    public void T get() {
        return this.map.get(Thread.currentThread());
    }
}

(kod neni dokonaly, ale jako nastrel dostacujici)

doufam ze sem vas jiz presvedcil o tom, ze jazyk Java s k objektum ThreadLocal stavi stejne jako k ostatnim a rozsah platnosti promene urcuji standardni modifikatory static,private,protected,public stejne jako u vsech ostatnich Objektu. Jeste vam pridam odkaz na Java Language Specification

Myslím, že autor měl na mysli, že "lokální proměnné vlákna" jsou speciální svým použitím, svojí sémantikou, ne že jsou nějak zvlášť speciální svojí implementací. Tak nevím, proč se tady hádáte.

Děkuji za odpověď, přesně v takovém duchu myslím i svůj příspěvek.

"Transakce je totiž automaticky zrušena, jakmile business metoda vyvolá výjimku, kterou nezachytí."
Toto platí pouze u runtime výjimek. Jinak se musí explicitně zavolat http://java.sun.com/javaee/5/docs/api/javax/ejb/EJBContext.html#setRollbackOnly()
Pozor na to! Ať se pak zbytečně nedivíte, že "v tý databázi je nějakej bordel" :-)

Ak si dobre pamatam, tak v EJB specifikacii sa rozlisuju dva typy vynimiek 1. systemove a 2. aplikacne.

Pri systemovych vynimkach sa transakcia automaticky rollbackuje kontajnerom pri kontajnerom manazovanych transakciach v pripade, ze nieje zachytena.

Je pravda, ze runtime vynimky su implicitne systemove, ale nieje to pravidlo, tj. na zmenu staci jedna anotacia alebo pripadne zapis v xml deskriptore aplikacie.

uvadet importy a vubec classpath...

A pokud nelze primo v clanku, tak alespon (nebo spise lepe) prilozit zdrojaky, nejlepe buildovane pomoci maven2 nebo ivy+ant (at to neni zavisle na IDE)

Dohledavat to v pripade, ze s tim dnes a denne nepracujete, je s prominutim "vopruz"...

Kazdopadne dekuji autorovi a preji hodne elanu...

Na dost zajímavé články ohledně transakcí v EJB jsem narazil na http://www.ibm.com/…raryview.jsp?…