I need to implement Ehcache in a project that uses Spring version 3.1 and Websphere. I tried to google something about this topic but I could'nt find anything. Have you guys ever used those three tools together? Thanks in advance.
As per EhCache docs,It will NOT detect Websphere Transaction Manager automatically,.
Automatically Detected Transaction Managers
Ehcache automatically detects and uses the following transaction
managers in the following order:
GenericJNDI (e.g. Glassfish, JBoss, JTOM and any others that register
themselves in JNDI at the standard location of
java:/TransactionManager
Weblogic (since 2.4.0)
Bitronix
Atomikos
No configuration is required; they work out of the box. The first found
is used.
And you can configure it as below.
If your Transaction Manager is not in the above list or you wish to
change the priority, provide your own lookup class based on an
implementation of net.sf.ehcache.transaction.manager.TransactionManagerLookup and
specify it in place of the DefaultTransactionManagerLookup in
ehcache.xml:
<transactionManagerLookup
class= "com.mycompany.transaction.manager.MyTransactionManagerLookupClass"
properties="" propertySeparator=":"/>
And to integrate & Use Spring with EhCache, refer this link
From Spring docs,
36.3 Declarative annotation-based caching For caching declaration, the abstraction provides a set of Java annotations:
#Cacheable triggers cache population #CacheEvict triggers cache eviction
#CachePut updates the cache without interfering with the method execution
#Caching regroups multiple cache operations to be applied on a
method
#CacheConfig shares some common cache-related settings at class-level
Related
I am trying to understand how the XADataSourceAutoConfiguration relates to the AtomikosJtaConfiguration and more generally the **JtaConfiguration.
More specifically how the two classes below relate to each other:
org.springframework.boot.autoconfigure.jdbc.XADataSourceAutoConfiguration
org.springframework.boot.autoconfigure.transaction.jta.AtomikosJtaConfiguration
I need a spring boot spring batch application to participate in transactions involving two databases.
Can someone please tell me how the two classes relate to each other?
I was not able to find much documentation in the javadocs API or in the reference documentation about XADataSourceAutoConfiguration.
XADataSourceAutoConfiguration is responsible for taking an XADataSource and applying a transaction manager-specific wrapper. That wrapper is how the data source is enlisted in any XA transactions.
AtomikosJtaConfiguration is responsible for configuring Atomikos, including providing the Atomikos-specific XADataSource wrapper that will ensure that Atomikos knows about the XADataSource and enlists it in any XA transactions.
I am planning to implement the Cache in the web application.
I have already used the Hibernate EHCache in one of my previous web application.
Now a days, recently i came to know that in latest Spring release there is Cache Abstraction layer.
Hence i would like to is it just wrapper of Hibernate EHCache or it is Cache features provided by Spring itself.
If different then would like to know which is best or better option to use Cache ?
Also, i came to know from few articles that Hibernate EHCache not supporting clustering, is it ? Because clustering required for big Web Application.
I have used Spring 3.1 and Hibernate 3.3 in Web Application.
Hibernate and EHCache are different things.
EHCache is the cache provider, i.e. the actual implementation of the cache.
Hibernate can use multiple different providers for the L2 cache, including EHCache.
Spring Cache is a framework for caching method calls. It can use multiple different providers, including EHCache.
EHCache offers distribution (clustering) in several modes, from basic JMS-driven synchronization to Terracotta BigMemory distribution. Hibernate L2 cache should support clustering.
Spring Cache has nothing to do with Hibernate, but you can use Hibernate L2 cache and Spring Cache (method caching) in parallel with EHCache as the underlying provider for both.
Just to add, for database-level caching using hibernate, hibernate/JPA second-level cache seems more appropriate. Because it manages data caching at entity level at the persistence context level (JPA APIs), so there are very fewer chances of inconsistency in database and cache, since hibernate manages it well.
But if we use spring cache for database caching, then we always have to ensure every method operating on database need to be annotated with appropriate cache annotation (For example, #CacheEvict for remove), so there are chances of missing annotations and causing inconsistency.
Also, spring cache can only be used on public methods, since it backed my AOP (We can use AspectJ though to solve this).
Hibernate caching continues to work with Spring using EhCache (or another caching provider). It offers a 2nd level cache for storing em.find(key) entities and relationships (#Cache annotations or XML), as well as query caching if you q.setHint("org.hibernate.cacheable",true). These are integrated and well-documented. Spring caching is not needed for this.
But Spring provides method caching which is independent of Hibernate caching, and can still use EhCache as the caching provider (sharing EhCache with Hibernate). This can be a little confusing because the EhCache configurations are overlapping, but essentially Spring Caching allows you to independently cache the results of methods that are marked as #Cacheable.
Note 1: Spring/Method caching is not integrated with Hibernate. Results cached with method caching are not recognized or maintained by Hibernate.
Note 2: Hibernate Query caching is not recommended for highly distributed systems without a good understanding of how the caching is used. It increases the risk of deadlocks due to the use of a shared entity timestamp cache that Hibernate maintains to keep track of when the cached query results should be evicted.
I am using the following versions:
Spring 3.1.1.RELEASE
Netty 3.4.0.Final
Hibernate 3.5.6-Final
Now, I have a Netty server that works fairly well - the root of the server, the pipeline factories and the base "stub" of the server that owns everything are all set up with Spring. In this stub, spring #Transactional annotations work just fine.
However, in the handlers, which are stateful and created dynamically depending on what state the user is in - #Transactional doesn't work. I'm fairly sure I understand why. I even have a "solution" - but it's not very good.
After the decoders and encoders, I add an ExecutionHandler:
pipeline.addLast("execution", new ExecutionHandler(new OrderedMemoryAwareThreadPoolExecutor(16,1000000, 1000000)));
This appears to be where the Spring transaction support is breaking. Since Spring is unaware of these threads, it can't bind any transactions to them. The classes are proxied correctly, but in debug they have no associated transactions.
My solution is crappy, and it needs to be replaced by a real solution:
Session sess = SessionFactoryUtils.getSession(getSessionFactory(), true);
That's bad because it relies on me to release the session, and it may not even be transactional, I haven't checked. It sucks in a lot of ways.
Anyway - the root of the question. Given the above tech, what's my path to getting my #Transactional notations working on the Netty handlers?
Write an ExecutionHandler that's Spring aware?
NOTE: I can't upgrade to Hibernate 4, due to lack of compatibility with Spring-Flex, used in another project in the group. Probably the same story for the Spring version, can't remember.
I suggest you create these netty's handler inside spring container and inject the service or persistence layer into the handlers so you can have these layers independence from netty and of course these are old school spring beans.
There are two entity manager factory beans in Spring that would work for my application. The org.springframework.orm.jpa.LocalEntityManagerFactoryBean and org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean. I am using Spring 3.0 with EclipseLink JPA 2.2.
What I've read about these two are that they are the same. Except that LocalContainerEntityManagerFactoryBean uses weaving. What is it? And, why would I want to use it?
"Weaving" is a term for program transformation, usually heard around "aspect oriented programming" area. The transformation is usually not done to the source but the .class (the bytecode) and a techy term for changing bytecode is "bytecode instrumentation".
why would I want to use it?
The JPA implementation you use may rely on such bytecode instrumentation for some features it provides and hence you might be forced into using it.
And for weaving to work correctly, you might need to specify a -javaagent: For eg,see section 'Eclipse Junit' here.
It looks like LocalContainerEntityManagerFactoryBean allows you to configure a weaver implementation ( one of DefaultContextLoadTimeWeaver, GlassFishLoadTimeWeaver, InstrumentationLoadTimeWeaver, OC4JLoadTimeWeaver, ReflectiveLoadTimeWeaver, SimpleLoadTimeWeaver, WebLogicLoadTimeWeaver
at an XML file, instead of relying on a -javaagent runtime argument.
This configuration isn't such a big factor, I'd guess.
Other features which the docs explain, sound like deciding factors.
LocalEntityManagerFactoryBean bootstrap is appropriate for standalone applications which solely use JPA for data access. If you want to set up your persistence provider for an external DataSource and/or for global transactions which span multiple resources, you will need to either deploy it into a full Java EE 5 application server and access the deployed EntityManagerFactory via JNDI, or use Spring's LocalContainerEntityManagerFactoryBean with appropriate configuration for local setup according to JPA's container contract.
If you plan on deploying your application to an Application Server and letting the Application Server manage the Entity Manager Factory and Transactions than the LocalContainerEntityManagerFactoryBean might be a better option. If you rather have the Application be more isolated, than the LocalEntityManagerFactoryBean would be more appropriate.
This blog can help provide more insight: http://second-kind-demon.blogspot.com/2011/06/spring-jpa-java-ee-jboss-deployment.html
How to not use (disable) transaction manager in spring configuration?
I'm doing simple app that will add rows to database, so no need in any transactions.
So, is it possible configure in xml, not to create any transaction managers?
PS: i use hibernate if this matters anyhow.
If you don't configure a Transaction Manager, neither will Spring. Just don't add any <tx:> tags and don't configure any PlatformTransactionManager beans (in your case HibernateTransactionManager).