dirtyread - how dirty read works in hibernate -

according manning's java persistence hibernate:

dirty read occurs if 1 transaction reads changes made transaction has not yet been committed. dangerous, because changes made other transaction may later rolled back, , invalid data may written first transaction.

if record retrieved database , there corresponding object been created in persistent state , whatever changes made , first written on persistent object , hence making dirty.

now question if other transaction reading same record , whether read record persistent state ie first level cache(which dirty @ moment) or retrieve record database.

first level cache not shared across transactions. except in case of extended persistence contexts common pattern used each transaction associated single session/persistence-context , has own first level cache being tracked transaction.

actually "dirty-read" property of database transaction , not hibernate in general. when 1 transaction reads changes made transaction has not yet been committed called dirty read. dangerous , unusual use type of transaction because read data might rolled back.

whatever changes made , first written on persistant object , hence making dirty.

what saying in above line there have been changes made object (but changes not yet sent database because orm's hibernate delay flushing sql till end of transaction). object after change dirty same cannot said transaction no insert/update/delete have been sent database.talking hibernate - reason considered "dirty" application perspective object representation of data read hibernate can changed using setters , object or data becomes "dirty" needs flushed database @ end of transaction or application may decide not commit. primary job of hibernate keep track of changed ("dirty") state , @ end of transaction generate appropriate insert/update/delete. dirtiness difference between state read , state after changes made if within same transaction.