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();
