I want to use Ehcache in my portlet application. If I want to remove data from cache, it is better to use #CacheEvict or #TriggersRemove?
According to documentation it looks like #CacheEvict and #TriggersRemove annotations are very similar.
disclaimer: I am working on the Spring caching abstraction (amongst other things).
These are two annotations from two different projects. I don't know much about TriggersRemove but from what I can see, it is ehcache specific.
The caching abstraction in the Spring Framework is completely decoupled from the underlying infrastructure so you can use that with basically any caching library out there, including ehcache. If you want your code to be independent from the caching library you use, I'd advise not to use TriggersRemove. If that's not a problem for you, check the documentation of each solution and choose accordingly.
Related
I am new to Spring cache abstraction. I have explored it using ehcache and apache ignite caching providers.
I want to know if spring cache abstraction supports the caching strategies of Write-behind and write-through.
Thanks,
bs
There is no direct support for cache-through in the declarative Spring abstraction.
And in a way it makes sense, since the abstraction lets you surround methods with caching related annotations. But with a cache-through pattern, the whole method would only be a cache interaction: a get for read, or a put for write. Not the if-then-else that the annotation abstracts.
However, if you use the CacheManager and Cache interfaces provided by Spring directly in your code, you can perfectly use them in a cache-through way.
Ignite cache has a notion of CacheStore interface that used in cases when there is a need to wire the cache with a persistent store (RDBMS, MongoDB, Hadoop, etc.). This interface provides write-through/write-behind and read-through semantics. Please refer to this documentation for more details.
Also I would recommend taking look at various examples that demonstrates how particular CacheStore implementations are used in Ignite. The examples are available in Ignite release bundles.
Spring is a popular framework, however I have difficulties to see in which situation the framework would actually help.
Currently I'm using the following:
* Tomcat
* Jersey
* Jackson
* Hibernate
Together this results in a Webservice, created by annotations, automatic JSON (un)marshalling and a comfortable Object/Relational Mapping.
So honestly at the moment I'm not missing anything, but I might just not know what great thing I'm missing... Could you help me out with this?
Thank you
Spring is a big framework providing a lot of functionality. It's hard to talk about advantages without knowing what functionality are you trying to use in the project.
Most probably you talk about Spring as an IoC container. It is very important part of Spring, but there is also AOP, transaction management, JDBC abstraction layer, authentication and authorization, testing and some more.
In a nutshell, Spring offers you uniform way to control dependencies between your objects. This is called inversion of control or dependency injection. Using it you can create pluggable, testable code that is easy to maintain.
In addition it gives you gazillion utility classes that just make life easier. For example, Hibernate is much easier to maintain via Spring facilities. It kind of brings together many different technologies under the same roof.
All websites state that the Spring core container is the basis for complete Spring framework i.e., it is used across
the all modules like AOP, JDBC module, Web module, etc. As per my understanding, the Spring core container's main purpose is
to inject dependencies, so avoiding the need of factory classes and methods. Is that correct?
Second question: When it is said, Spring core container is the basis for complete Spring framework (e.g., for Spring AOP). As per my understanding, in Spring AOP also, getting the object of classes like
ProxyFactoryBean is achieved by core container. Right?
Thirdly, it is stated that Spring core container avoids the need for programming the use of singletons. How come singleton
classes are avoided by core container?
yep
yep
All beans declared in Spring config files are singleton by default. They are instantiated when your application starts.
First off, your understanding of what you get from Spring is about right. So let's get on to your third question, the interesting one.
The key is it's not that you don't have singletons, it's that they're singletons by configuration. This is a vital difference, as it means you can avoid all the complicated singleton enforcement code (the source of frequent problems) and instead just write exceptionally simple programs that focus on the business end of things. This is particularly important when you are writing a program with non-trivial object lifetimes: for example, in a webapp it makes it very easy to manage the lifespan of objects that hold state associated with a user's session, since if the objects have session scope, they'll be “singleton per user session”. That's enormously easier to work with than many of the alternatives.
The fact that Spring can also help out with transactions is just perfect as transaction handling is distinctly non-trivial, and AOP is the best solution to them in Java that I've seen (other languages have other options open) with Spring supporting a pretty straight-forward way of doing it. Try to do it properly without if you don't believe me. Spring's pretty much wonderful.
Spring MVC 3.0 with Annotation seems like a great framework for the enterprise web development. However, the issue of performance tuning often comes up when you deal with any web applications, and I am wondering how the use of Annotations affects the strategy for improving performance. For example, would the Annotation-based validations slow down the system? Are the annotated classes, controllers, beans performing as well as those defined with the XML? Would the fact that the Annotations in Spring 3.0 MVC allow such dynamic and flexible request mappings can potentially make the performance measurement and tuning more difficult?
In my opinion annotation approach must have exactly the same performance as XML approach. In both cases Spring creates some BeanFactoryPostProcessor instances and another kinds of helper objects which use different sources of information (XML or annotations), but do exactly the same thing: update bean definitions, create proxies around beans, create some infrastructure objects and so on.
Anyway, #skaffman is right. You could try both approaches and do some profiling.
Most (if not all) of the annotations (and other configurations) are handled during startup. So it doesn't have any hit on performance. (They may only slow down startup, but that should be negligible)
Spring Modules had a #Cacheable annotation:
org.springmodules.cache.annotations.Cacheable
Now that Spring Module is deprecated, what is the recommendation for caching? And is still still possible to work with ehCache?
Users of Spring Modules have rather been left out on a limb. There's no direct replacement for #Cacheable that I'm aware of.
Spring does have some support for EhCache, though, in the form of EhCacheFactoryBean and related classes (see javadoc). This gives a pretty easy way of creating and managing EhCache instances, but you then have to make use of it manually.
The distribute cache server is memcached. I has api to java.
http://memcached.org/
This project is intended as a direct replacement: http://code.google.com/p/ehcache-spring-annotations/
This is now found in spring-context. I have not checked how far back it is, but it is in the 4.1.4.RELEASE.
\org\springframework\cache\annotation\