Spring + Hibernate + JPA + multiple databases

Either way will add an entity to a PersistenceContext, the difference is in what you do with the entity afterwards.

Persist takes an entity instance, adds it to the context and makes that instance managed (ie future updates to the entity will be tracked).

Merge returns the managed instance that the state was merged to. It does return something what exists in PersistenceContext or creates a new instance of your entity. In any case, it will copy the state from the supplied entity, and return managed copy. The instance you pass in will not be managed (any changes you make will not be part of the transaction - unless you call merge again). Though you can use the returned instance (managed one).

Maybe a code example will help.

MyEntity e = new MyEntity();

// scenario 1
// tran starts
em.persist(e); 
e.setSomeField(someValue); 
// tran ends, and the row for someField is updated in the database

// scenario 2
// tran starts
e = new MyEntity();
em.merge(e);
e.setSomeField(anotherValue); 
// tran ends but the row for someField is not updated in the database
// (you made the changes *after* merging)
      
// scenario 3
// tran starts
e = new MyEntity();
MyEntity e2 = em.merge(e);
e2.setSomeField(anotherValue); 
// tran ends and the row for someField is updated
// (the changes were made to e2, not e)

Scenario 1 and 3 are roughly equivalent, but there are some situations where you'd want to use Scenario 2.

Ok, I figured out the problem. It took me forever to figure it out and had nothing to do with my database config, so I want to help people who have similar issues.

The Spring documentation states the following:

<tx:annotation-driven/> only looks for @Transactional on beans in the same application context it is defined in. This means that, if you put <tx:annotation-driven/> in a WebApplicationContext for a DispatcherServlet, it only checks for @Transactional beans in your controllers, and not your services. See Section 15.2, “The DispatcherServlet” for more information.

What's not posted in my original post is my servlet definition, which has the following lines of configuration code:

myServlet.xml

<context:annotation-config /> 
<context:component-scan base-package="com.myDomain.*" /> 

This brings all annotated beans, including Controllers, Services and Repositories, into the servlet context instead of the application context. And therein lies the problem. When Spring looks for beans annotated with @Transactional (due to the existence of <tx:annotation-driven/> in my config.xml file) it is looking for them in the application context. And, based on my config that was posted in my previous thread, there are no beans being loaded into my application context... they're all in the servlet context. Therefore, when my servlet was calling the beans annotated with @Service & @Transactional it was using beans that were not wrapped by transaction proxies. Thus, no transactions. The trick (rather, the correct way) was to change my config files in the following way:

myServlet.xml

<context:annotation-config /> 
<context:component-scan base-package="com.myDomain.servlets" /> 

config.xml

<context:annotation-config /> 
<context:component-scan base-package="com.myDomain.dao" /> 
<context:component-scan base-package="com.myDomain.services" /> 

This configuration ensures that all Controllers exist in the servlet context and Transactional Services and Repositories exist in the application context, which is where they belong. And finally, after many sleepless nights, my database writes are persisting.