I was hoping I could use a long running "user/application" transaction or what is sometimes called conversation in a certain scenario like so....
1. begin conversation
2. tx 1....load list of stuff I need to process
3. tx 2...process first item in list
4. tx 3...process second item in list
5. tx 4...process third item in list
6. etc. etc. etc.
If 4 fails and gets rolled back, I want 5 to still go. I would almost expect the entire cache at step 4 to be flushed so my changes would not be persisted. It seems though with hibernate that step 5 is dead because step 4 failed....Here is my test code below.....
EntityManagerFactory sf = Persistence.createEntityManagerFactory( "xcoreNonJta", null); EntityManager mgr = sf.createEntityManager(); org.hibernate.Session session = (org.hibernate.Session) mgr.getDelegate(); session.setFlushMode(org.hibernate.FlushMode.MANUAL); //verify we are in flush manual mode first by NOT flushing!! mgr.getTransaction().begin(); Users user = Users.getUserById(mgr, "admin"); user.setCountry("USACCCCC"); mgr.getTransaction().commit(); mgr.getTransaction().begin(); user.setAddress1("addr1CCCCC"); //written to db 3 lines later during commit!!! mgr.flush(); //NOTE: whatever changes are above flush are persisted at commit time user.setAddress2("addr2CCCCC"); //not written to db at all due to rollback and after flush mgr.getTransaction().commit(); mgr.getTransaction().begin(); user.setCity("city1"); //not written to db because of the rollback even though flush is called mgr.flush(); mgr.getTransaction().rollback(); mgr.getTransaction().begin(); user.setAddress1("addr1DDDDD"); //not written to db, the cache appears to be forever dead!!! mgr.flush(); user.setAddress2("addr2DDDDD"); mgr.getTransaction().commit(); mgr.close(); sf.close();