2009/6/19 Pavel Nemec <[email protected]>
>
>
> 2009/6/19 Lukas Barton <[email protected]>
>
>> V prvnim pripade musite volat session.get. Session.load udela proxy, ktera
>> se inicializuje az po pristoupeni na jeji property.
>
>
> Bohuzel toto nepomaha. Bez ohledu, zda volam .load, nebo .get a zda po tom
> provedu flush, tak je stale mozne rucne zmenit dany radek databaze - coz je
> to cemu potrebuji zabranit
>
> Session.flush je zbytecne, toto volani synchronizuje stav v pameti se
>> stavem v DB, nikoliv naopak.
>
> ano to se skutecne pise v javadocu a vim to. Nicmene jsem zjistil ze .flush
> mimo jine take zapise aktualni zmeny provedene v ramci transakce do db.
> Dokonce pokud provedu zmeny zavolam flush a pak rollback, tak tyto zmeny
> nejsou vraceny.
>
Zmeny vraceny byt musi, flush jen posle prikazy do DB, commit se dela
zvlast.
Dokonce Hibernate muze posilat prikazy do DB v libovolnem poradi a nektere
nemusi poslat vubec.
Nejedete v autocommit modu? To by vysvetlovalo i ten problem s nezamykanim
pri GETu.
Lukas
>
>
> Zacinam cist Java persistance with Hibernate, ktera mi snad da na tyto veci
> odpovedi.
>
>
>> session.createSQLQuerry("LOCK TABLE mytable WRITE) neudela nic, jen
>> vytvori objekt SqlQuery.
>> Na tomto objektu musite zavolat executeUpdate.
>> Flush je zase zbytecny.
>
>
> ja jsem si rikal ze se to musi executnout. Jenze jsem hledal metodu execute
> :) Dik tohle uz mi funguje.
>
>>
>>
>> Doporucil bych si precist tu dokumentaci celou :-)
>> A javadoc vsech metod na tride Session.
>
>
> No tak knizka ma 800 stran, takze tohle bude chvili trvat.
>
> Kazdopadne dik za pomoc.
>
> Pavel
>
>
