We Keep Coding

Spring JPA - create N repositories for N databases [duplicate]

I am working in a project using Spring, Spring Data JPA, Spring Security, Primefaces...
I was following this tutorial about dynamic datasource routing with spring.
In this tutorial, you can only achieve dynamic datasource switching between a pre-defined datasources.
Here is a snippet of my code :
springContext-jpa.xml
<bean id="dsCgWeb1" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="${jdbc.driverClassName.Cargest_web}"></property>
<property name="url" value="${jdbc.url.Cargest_web}"></property>
<property name="username" value="${jdbc.username.Cargest_web}"></property>
<property name="password" value="${jdbc.password.Cargest_web}"></property>
</bean>
<bean id="dsCgWeb2" class="org.apache.commons.dbcp.BasicDataSource">
// same properties, different values ..
</bean>
<!-- Generic Datasource [Default : dsCargestWeb1] -->
<bean id="dsCgWeb" class="com.cargest.custom.CargestRoutingDataSource">
<property name="targetDataSources">
<map>
<entry key="1" value-ref="dsCgWeb1" />
<entry key="2" value-ref="dsCgWeb2" />
</map>
</property>
<property name="defaultTargetDataSource" ref="dsCgWeb1" />
</bean>
What i want to do is to make the targetDataSources map dynamic same as its elements too.
In other words, i want to fetch a certain database table, use properties stored in that table to create my datasources then put them in a map like targetDataSources.
Is there a way to do this ?

Nothing in AbstractRoutingDataSource forces you to use a static map of DataSourceS. It is up to you to contruct a bean implementing Map<Object, Object>, where key is what you use to select the DataSource, and value is a DataSource or (by default) a String referencing a JNDI defined data source. You can even modify it dynamically since, as the map is stored in memory, AbstractRoutingDataSource does no caching.
I have no full example code. But here is what I can imagine. In a web application, you have one database per client, all with same structure - ok, it would be a strange design, say it is just for the example. At login time, the application creates the datasource for the client and stores it in a map indexed by sessionId - The map is a bean in root context named dataSources
#Autowired
#Qualifier("dataSources");
Map<String, DataSource> sources;
// I assume url, user and password have been found from connected user
// I use DriverManagerDataSource for the example because it is simple to setup
DataSource dataSource = new DriverManagerDataSource(url, user, password);
sources.put(request.getSession.getId(), dataSource);
You also need a session listener to cleanup dataSources in its destroy method
#Autowired
#Qualifier("dataSources");
Map<String, DataSource> sources;
public void sessionDestroyed(HttpSessionEvent se) {
// eventually cleanup the DataSource if appropriate (nothing to do for DriverManagerDataSource ...)
sources.remove(se.getSession.getId());
}
The routing datasource could be like :
public class SessionRoutingDataSource extends AbstractRoutingDataSource {
#Override
protected Object determineCurrentLookupKey() {
HttpServletRequest request = ((ServletRequestAttributes)
RequestContextHolder.getRequestAttributes()).getRequest();
return request.getSession().getId();
}
#Autowired
#Qualifier("dataSources")
public void setDataSources(Map<String, DataSource> dataSources) {
setTargetDataSources(dataSources);
}
I have not tested anything because it would be a lot of work to setting the different database, but I thing that it should be Ok. In real world there would not be a different data source per session but one per user with a count of session per user but as I said it is an over simplified example.

The datasource used by a thread might change from time to time.
Should pay attention to concurrency, applications might get concurrency issues in concurrent environment.
thread-bound AbstractRoutingDataSource sample

It can be achieved with AbstractRoutingDataSource and keeping the information in the thread-local Variable. Here is a beautiful working example you can refer to:
Multi-tenancy: Managing multiple datasources with Spring Data JPA

Getting "org.hibernate.LazyInitializationException" exceptions after retrieving items from my second-level ehcache

I'm using Hibernate 5.1.0.Final with ehcache and Spring 3.2.11.RELEASE. I have the following #Cacheable annotation set up in one of my DAOs:
#Override
#Cacheable(value = "main")
public Item findItemById(String id)
{
return entityManager.find(Item.class, id);
}
The item being returned has a number of assocations, some of which are lazy. So for instance, it (eventually) references the field:
#ManyToMany(fetch = FetchType.LAZY)
#JoinTable(name = "product_category", joinColumns = { #JoinColumn(name = "PRODUCT_ID") }, inverseJoinColumns = { #JoinColumn(name = "CATEGORY_ID") })
private List<Category> categories;
I notice that within one of my methods that I mark as #Transactional, when the above method is retrieved from the second level cache, I get the below exception when trying to iterate over the categories field:
#Transactional(readOnly=true)
public UserContentDto getContent(String itemId, String pageNumber) throws IOException
{
Item Item = contentDao.findItemById(ItemId);
…
// Below line causes a “LazyInitializationException” exception
for (Category category : item.getParent().getProduct().getCategories())
{
The stack trace is:
16:29:42,557 INFO [org.directwebremoting.log.accessLog] (ajp-/127.0.0.1:8009-18) Method execution failed: : org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: org.mainco.subco.ecom.domain.Product.standardCategories, could not initialize proxy - no Session
at org.hibernate.collection.internal.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:579) [hibernate-myproject-5.1.0.Final.jar:5.1.0.Final]
at org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:203) [hibernate-myproject-5.1.0.Final.jar:5.1.0.Final]
at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:558) [hibernate-myproject-5.1.0.Final.jar:5.1.0.Final]
at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:131) [hibernate-myproject-5.1.0.Final.jar:5.1.0.Final]
at org.hibernate.collection.internal.PersistentBag.iterator(PersistentBag.java:277) [hibernate-myproject-5.1.0.Final.jar:5.1.0.Final]
at org.mainco.subco.ebook.service.ContentServiceImpl.getCorrelationsByItem(ContentServiceImpl.java:957) [myproject-90.0.0-SNAPSHOT.jar:]
at org.mainco.subco.ebook.service.ContentServiceImpl.getContent(ContentServiceImpl.java:501) [myproject-90.0.0-SNAPSHOT.jar:]
at sun.reflect.GeneratedMethodAccessor819.invoke(Unknown Source) [:1.6.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_65]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_65]
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) [spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) [spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) [spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:96) [spring-tx-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:260) [spring-tx-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:94) [spring-tx-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) [spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) [spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) [spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
at com.sun.proxy.$Proxy126.getContent(Unknown Source)
I understand what the Hibernate session is closed — I do not care about why this happens. Also, it is NOT an option o make the above association eager (instead of lazy). Given that, how can I solve this problem?
Edit: Here is how my ehccahe.xml is configured …
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../config/ehcache.xsd" updateCheck="false">
<!-- This is a default configuration for 256Mb of cached data using the JVM's heap, but it must be adjusted
according to specific requirement and heap sizes -->
<defaultCache maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="86400"
timeToLiveSeconds="86400"
overflowToDisk="false"
memoryStoreEvictionPolicy="LRU">
</defaultCache>
<cache name="main" maxElementsInMemory="10000" />
<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.1,
multicastGroupPort=4446, timeToLive=32"/>
<cacheManagerPeerListenerFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"
properties="hostName=localhost, port=40001,
socketTimeoutMillis=2000"/>
</ehcache>
and here is how I’m plugging it into my Spring context …
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="packagesToScan" value="org.mainco.subco" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"/>
</property>
<property name="dataSource" ref="dataSource"/>
<property name="jpaPropertyMap" ref="jpaPropertyMap" />
</bean>
<cache:annotation-driven key-generator="cacheKeyGenerator" />
<bean id="cacheKeyGenerator" class="org.mainco.subco.myproject.util.CacheKeyGenerator" />
<bean id="cacheManager"
class="org.springframework.cache.ehcache.EhCacheCacheManager"
p:cacheManager-ref="ehcache"/>
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"
p:configLocation="classpath:ehcache.xml"
p:shared="true" />
<util:map id="jpaPropertyMap">
<entry key="hibernate.show_sql" value="false" />
<entry key="hibernate.hbm2ddl.auto" value="validate"/>
<entry key="hibernate.dialect" value="org.hibernate.dialect.MySQL5InnoDBDialect"/>
<entry key="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup" />
<entry key="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.EhCacheRegionFactory"/>
<entry key="hibernate.cache.provider_class" value="org.hibernate.cache.EhCacheProvider"/>
<entry key="hibernate.cache.use_second_level_cache" value="true" />
<entry key="hibernate.cache.use_query_cache" value="false" />
<entry key="hibernate.generate_statistics" value="false" />
</util:map>
<bean id="entityManager" class="org.springframework.orm.jpa.support.SharedEntityManagerBean">
<property name="entityManagerFactory" ref="entityManagerFactory"/>
</bean>

Take a look at a similar question. Basically, your cache is not a Hibernate second-level cache. You are accessing a lazy uninitialized association on a detached entity instance, so a LazyInitializationException is expected to be thrown.
You can try to play around with hibernate.enable_lazy_load_no_trans, but the recommended approach is to configure Hibernate second level cache so that:
Cached entities are automatically attached to the subsequent sessions in which they are loaded.
Cached data is automatically refreshed/invalidated in the cache when they are changed.
Changes to the cached instances are synchronized taking the transaction semantics into consideration. Changes are visible to other sessions/transactions with the desired level of cache/db consistency guarantees.
Cached instances are automatically fetched from the cache when they are navigated to from the other entities which have associations with them.
EDIT
If you nevertheless want to use Spring cache for this purpose, or your requirements are such that this is an adequate solution, then keep in mind that Hibernate managed entities are not thread-safe, so you will have to store and return detached entities to/from the custom cache. Also, prior to detachment you would need to initialize all lazy associations that you expect to be accessed on the entity while it is detached.
To achieve this you could:
Explicitly detach the managed entity with EntityManager.detach. You would need to detach or cascade detach operation to the associated entities also, and make sure that the references to the detached entities from other managed entities are handled appropriately.
Or, you could execute this in a separate transaction to make sure that everything is detached and that you don't reference detached entities from the managed ones in the current persistence context:
#Override
#Cacheable(value = "main")
#Transactional(propagation = Propagation.REQUIRES_NEW)
public Item findItemById(String id) {
Item result = entityManager.find(Item.class, id);
Hibernate.initialize(result.getAssociation1());
Hibernate.initialize(result.getAssociation2());
return result;
}
Because it may happen that the Spring transaction proxy (interceptor) is executed before the cache proxy (both have the same default order value: transaction; cache), then you would always start a nested transaction, be it to really fetch the entity, or to just return the cached instance.
While we may conclude that performance penalty for starting unneeded nested transactions is small, the issue here is that you leave a small time window when a managed instance is present in the cache.
To avoid that, you could change the default order values:
<tx:annotation-driven order="200"/>
<cache:annotation-driven order="100"/>
so that cache interceptor is always placed before the transaction one.
Or, to avoid ordering configuration changes, you could simply delegate the call from the #Cacheable method to the #Transactional(propagation = Propagation.REQUIRES_NEW) method on another bean.

What you implemented in your code snippets is a custom cache based on spring-cache. With your implementation you would need to take care of cache evictions, making sure that at the point when your object graphs will get cached they are properly loaded, etc. Once they get cached and the original hibernate session that loaded them is closed they'll become detached, you can no longer navigate unfetched lazy associations. Also, your custom cache solution in its current state would cache entity graphs, which is probably not what you want, since any part of that graph might change at a given time, and your cache solution would need to watch for changes in all parts of that graph to properly handle evictions.
The configuration you posted in your question is not Hibernate second-level cache.
Managing a cache is a complex endeavor and I don't recommend it doing it by yourself, unless you're absolutely sure what you're doing (but then you won't be asking this question on Stackoverflow).
Let me explain what is happening with when you get the LazyInitializationException: you marked one of your dao methods with #org.springframework.cache.annotation.Cacheable. What happens in this case is the following:
Spring attaches an interceptor to your managed bean. The interceptor will intercept the dao method call, it will create a cache key based on the interceptor method and the actual method arguments (this can be customized), and look up the cache to see if there's any entry in the cache for that key. In case there's an entry it will return that entry without actually invoking your method. In case there's no cache entry for that key, it will invoke your method, serializes the return value and store it in the cache.
For the case when there was no cache entry for the key, your method will get invoked. Your method uses a spring provided singleton proxy to the thread bound EntityManager which was assigned earlier when Spring encountered the first #Transactional method invocation. In your case this was the getContent(...) method of another spring service bean. So your method loads an entity with EntityManager.find(). This will give you a partially loaded entity graph containing uninitialized proxies and collections to other associated entities not yet loaded by the persistence context.
Your method returns with the partially loaded entity graph and spring will immediately serialize it for you and store it in the cache. Note that serializing a partially loaded entity graph will deserialize to a partially loaded entity graph.
On the second invocation of the dao method marked with #Cacheable with the same arguments, Spring will find that there is indeed an entry in the cache corresponding to that key and will load and deserialize the entry. Your dao method will not be called since it uses the cached entry. Now you encounter the problem: your deserialized cached entity graph was only partially loaded when you stored in the cache, and as soon as you touch any uninitialized part of the graph you'll get the LazyInitializationException. A deserialized entity will always be detached, so even if the original EntityManager would be still open (which is not), you would still get the same exception.
Now the question is: what can you do to avoid the LazyInitializationException. Well, my recommendation is that you forget about implementing a custom cache and just configure Hibernate to do the caching for you. I will talk about how to do that later. If you want to stick with the custom cache you tried to implement, here's what you need to do:
Go through your whole code base and find all invocations of your #Cacheable dao method. Follow all possible code paths where the loaded entity graph is passed around and mark all parts of the entity graph which ever gets touched by client code. Now go back to your #Cacheable method and modify it so that it loads and initializes all parts of the entity graph that would ever get possibly touched. Because once you return it and it gets serialized, and deserialized later, it will always be in a detached state so better make sure all possible graph paths are properly loaded. You should already feel how impractical this will end up. If that still didn't convince you not to follow this direction, here's another argument.
Since you load up a potentially big chunk of the database, you will have a snapshot of that part of the database at the given time when it got actually loaded and cached. Now, whenever you use a cached version of this big chunk of the database, there's is a risk that you are using a stale version of that data. To defend from this, you would need to watch for any changes in the current version of that big chunk of the database you just cached and evict the whole entity graph from the cache. So you pretty much need to take into account which entities are parts of your entity graph and set up some event listeners whenever those entities are changed and evict the whole graph. None of these issues are present with Hibernate second-level cache.
Now back to my recommendation: set up Hibernate second-level cache
Hibernate second-level cache is managed by Hibernate and you get eviction management from hibernate automatically. If you have Hibernate second-level cache enabled, Hibernate will cache the data needed to reconstruct your entities and, if - when seeking to load an entity from the database - it finds that it has a valid cache entry for your entity, it will skip hitting the database and reconstruct your entity from its cache. (Mark the difference to caching an entity graph with its possibly unfetched associations and uninitialized proxies in your custom cache solution). It will also replace stale cache entries when you update an entity. It does all sorts of things related to managing the cache so that you don't have to worry about it.
Here's how can you enable Hibernate second-level cache: in addition to your configuration do the following:
In addition to the hibernate properties you already have for second-level management, namely
<entry key="hibernate.cache.region.factory_class" value="org.hibernate.cache.ehcache.EhCacheRegionFactory"/>
<entry key="hibernate.cache.provider_class" value="org.hibernate.cache.EhCacheProvider"/>
<entry key="hibernate.cache.use_second_level_cache" value="true" />
add the following entry:
<entry key="javax.persistence.sharedCache.mode" value="ENABLE_SELECTIVE" />
alternatively, you could add a shared-cache-mode configuration option to your persistence.xml (since you didn't post it, I assumed you don't use it hence the previous alternative; the following one is preferred though):
<persistence-unit name="default">
<!-- other configuration lines stripped -->
<shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
<!-- other configuration lines stripped -->
</persistence-unit>
Add javax.persistence.#Cacheable annotation to your #Entity classes you want to be cacheable.
If you want to add caching for collection valued associations which Hibernate doesn't cache by default, you can add a #org.hibernate.annotations.Cache annotation (with a proper cache concurrency strategy choice) for each such collection:
#ManyToMany(fetch = FetchType.LAZY)
#JoinTable(name = "product_category", joinColumns = { #JoinColumn(name = "PRODUCT_ID")
}, inverseJoinColumns = { #JoinColumn(name = "CATEGORY_ID") })
#Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
private List<Category> categories;
See Improving performance/The Second Level Cache in the Hibernate Reference Documentation for further details.
This is a nice informative article about the subject: Pitfalls of the Hibernate Second-Level / Query Caches
I have put together a small project based on your posted code snippets which you can check out to see Hibernate second-level cache in action.

The problem is that you are caching references to objects which are loaded lazily. Cache the object once it is all loaded or do not use the cache at all.
Here is how you could load the categories manually before caching it:
Item item = entityManager.find(Item.class, id);
item.getParent().getProduct().getCategories();
return item;
Also a better caching strategy would be to have the cache at the service level of your application instead of the DAO level or no cache at all.
Your issue is caused by the following events:
An Item is being retrieved without its categories then put in the cache in transaction 1. In transaction 2, you call the same method and retrieve the Item and try to read its categories. At that moment hibernate tries to read the categories from transaction 1 which is associated to the Item object but transaction 1 is already completed so it fails.

I used simple type cache with this config as below:
spring.jpa.properties.hibernate.enable_lazy_load_no_trans=true
spring.jpa.open-in-view=true
spring.cache.type=simple

Ehcache Distributed Multiple channel

I am using ehcache in ditributed mode .
The caches are synchronized by channel .
<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
properties="channelName=CHANNEL1:connect=UDP(mcast_port=45568)"
propertySeparator=":" />
For a new requirement , i need to synch with two channels : CHANNEL1 and CHANNEL2 .
Is this possible ? if yes , how i can do that ?
Thanks in advance

Usually One instance of cacheManagerPeerProviderFactory is used to replicate ( or Synchronize) number of caches across cluster. In that case, "channelName=CHANNEL1:" is more like simply giving a name. I don't think ehCache supports multiple channels.
If you're requirement is to have some replication specific one channel, you can try one of the following
Run two EhCache Managers in the same application each with it's ehcache.xml, One for the specific replication logic, and one for the common replication logic of caches.
You will have only one cache manager, but your ehcache.xml will vary in a way that, you won't include the cache ( which requires specific replication logic) with in the third application.
First one is more cleaner approach.
You can have multiple EhcacheManagers with Spring in following way,
<ehcache:annotation-driven cache-manager="ehCacheManager1" />
<bean id="ehCacheManager1" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="configLocation" value="classpath:ehcache-1.xml" />
</bean>
<bean id="ehCacheManager2" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="configLocation" value="classpath:ehcache-2.xml" />
</bean>

Spring Cache Manager add new cache without anotations

I can get items out of the cache manager by using
cachemanager.getCache("cachename").get(cacheKey)
How do I add a new cache via the cache manager? There appears to be only getCache() and getCacheNames().
There is getCache("newcachename").put(cacheKey) but that fails as "newcachename" doesn't exist.

Sorted, my fault. I didnt add the new cache details to the ehcache.xml file.
<cache name="newcachename" maxElementsInMemory="10000"
eternal="false" timeToIdleSeconds="300" timeToLiveSeconds="300"
overflowToDisk="false" diskPersistent="false"/>
Once I added this I could use
getCache("newcachename").put(cacheKey, "value to cache")
Thanks all for your assistance.

I don't know exactly what you configuration looks like so I can't give a more detailed explanation, but I have successfully used multiple caches using Spring's CompositeCacheManager

<set>
<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="newcachename" />
</set>
Have you set up this cache for this cacheName in the configurations?

hibernate doesn't issue update after flush

I'm using hibernate 3.2.7 (same problem on 3.2.5) with spring 3.0.1, all deployed on weblogic 10.3 and with an Oracle 10g database. I'm using JTA transaction management and the transaction is distributed (it is actually started and ended in another application, this code is just in between).
The configuration used by hibernate is declared in my persistence.xml and is the following:
<property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"/>
<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.WeblogicTransactionManagerLookup"/>
<property name="hibernate.query.factory_class" value="org.hibernate.hql.classic.ClassicQueryTranslatorFactory"/>
<property name="hibernate.current_session_context_class" value="jta"/>
<property name="hibernate.connection.release_mode" value="auto"/>
The spring configuration regarding the transaction manager is the following:
<!-- Instructs Spring to perfrom declarative transaction managemenet on annotated classes -->
<tx:annotation-driven transaction-manager="txManager" proxy-target-class="true"/>
<!-- Data about transact manager and session factory -->
<bean id="txManager" class="org.springframework.transaction.jta.WebLogicJtaTransactionManager">
<property name="transactionManagerName" value="javax.transaction.TransactionManager"/>
<property name="defaultTimeout" value="${app.transaction.timeOut}"/>
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<!-- persistence unit is missing jta data source so that application server is not
creating EntitiyManagerFactory, spring will create its own LocalContainerEntityManagerFactoryBean overriding data source-->
<property name="dataSource" ref="myDataSource"/>
<!-- specific properties like jpa provider and jpa provider properties are in persistance unit -->
<property name="persistenceUnitName" value="my.persistence.unit"/>
</bean>
<!-- define data source in application server -->
<jee:jndi-lookup id="myDataSource" jndi-name="${db.jndiName}"/>
I'm using a generic CrudDao with an update method that looks like this:
public void update(Object entity) {
//entityManager injected by #PersistenceContext
entityManager.merge(entity);
entityManager.flush();
}
public Object getById(Object id, Class entityClass) throws PersistenceException{
return (Object)entityManager.find(entityClass, id);
}
UPDATED: added the getById method.
The code that does not work as expected looks like this:
MyObject myObj = getMyObjectThroughSomeOneToManyRelation(idOne, idOther);
// till now was null
myObj.setSomeDateAttr(someDate);
genericDao.update(myObj);
MyObject myObjFromDB = genericDao.getById(myObj.getId(), MyObject.class);
The result is that if I print myObj.getSomeDateAttr() it returns me the value of someDate, if I print myObjFromDB.getSomeDateAttr() it still has null.
I've tried changing the update method to:
org.hibernate.Session s = (org.hibernate.Session) entityManager.getDelegate();
s.evict(entity);
s.update(entity);
s.flush();
And it still doesn't work.
When turning on the show_sql flag of hibernate I don't see any update occurring when doing flush nor when I query the entity manager for the object with the same id. The selects are all visible.
UPDATE:
At the end of the transaction the update is actually called and everything is written to the db. So my problem is "just" during the transaction.
I'm afraid the problem may be linked with the configuration of the transaction manager on spring and on hibernate.
Hope that someone can help me as I have already lost a day and a half with no luck.

You need to look at the hibernate merge behaviour closely. As per documentation
if there is a persistent instance with the same identifier currently
associated with the session, copy the state of the given object onto
the persistent instance
if there is no persistent instance currently associated with the session, try to load it from the database, or create a new persistent instance
the persistent instance is returned
the given instance does not become associated with the session, it
remains detached
As per your statement on the sql queries in log, it look like
MyObject myObj = getMyObjectThroughSomeOneToManyRelation(idOne, idOther); returning the persistent object but when you modify it(becomes dirty) and call merge method, new state is copied to the current persistent object in session. If you see third point merge returns persistent object which is actually new manageable persistent object which you need to use in subsequent operations.
When you call find method hibernate returns the persistent object in session and not maneagable persistent object thats why you dont find the changes in object return by find.
To fix your problem change the reurn type of update method
public Object update(Object entity) {
//entityManager injected by #PersistenceContext
return entityManager.merge(entity);
}
and in service you need to use as below
MyObject myObj = getMyObjectThroughSomeOneToManyRelation(idOne, idOther);
// till now was null
myObj.setSomeDateAttr(someDate);
//You can use myObj as well instead myNewObj
MyObject myNewObj= genericDao.update(myObj);
//No need to call get
//MyObject myObjFromDB = genericDao.getById(myObj.getId(), MyObject.class);
System.out.println("Updated value:"+myNewObj.getSomeDateAttr());
Have a look at this artical as well.