Spring caching - auto update cached setter - spring

I am really new to spring caching.
I saw that spring caching annotations are based mostly on annotating methods.
My question is if i have a dao class that has the following method:
public User getUserById(long id);
And lets say i cache this method.
and have another dao method (with no annotation) like:
public void updateUser(User u);
Now imagine this scenario:
1) someone invokes the getUserById(user1Id); //(cache of size 1 now has user1)
2) someone else invokes the updateUser(User1) ; // lets say a simple name change
3) someone else invokes the getUserById(user1Id);
My question :
Assuming no other actions were taken, Will the 3rd invocation receives a deprecated data? (with the old name)?
If so , how to solve this simple use case?

Yes, the third invocation will return a stale data.
To overcome this, you should trigger a cache eviction after the update operation, by annotating your update method with a #CacheEvict annotation:
#CacheEvict(value = "users", key = "#user.id")
void updateUser(User user) {
...
}
Where value = "users" is the same cache name you had used for getUserById() method, and User class has an id property of type Long (which is used as the users cache key)

You need to remove the stale items from cache. The Spring framework helps with several caching related annotations (you could annotate the update-method with #CacheEvict for example). Spring has a good documentation on caching by the way.

Related

Spring service with in-memory list

I want to have a service which keeps a list inmemory so I don't need to access the database everytime. The service is accessed by a controller. Is this a valid approach or am I missing something? What about concurrent access here (from the controller)? Is this (stateful service) an anti-pattern?
#Service
public class ServiceCached {
private List<SomeObject> someObjects;
#PostConstruct
public void initOnce() {
someObjects = /** longer running loading methodd **/
}
public List<SomeObject> retrieveObjects() {
return someObjects;
}
}
Thanks!
I wouldn't call it an anti-pattern, but in my opinion loading the list from the database in a #PostConstruct method is not a good idea as you slow down the start up of your application, I'd rather use a lazy loading mechanism, but this would potentially introduce some concurrent access issues that would need to be handled.
In your example concurrent access from the controller should not be a problem as the list is loaded from a #PostConstruct method and the controller would depend on this service, therefore this service would need to be fully constructed before it is injected into the controller, therefore the list would already be loaded.
Preferably I'd suggest using Spring Caching: Caching Data with Spring, Documentation, Useful guide
Usage example:
#Cacheable("books")
public Book getByIsbn(String isbn) {
simulateSlowService();
return new Book(isbn, "Some book");
}
This way you do not need to take care of loading and evicting the objects. Once set up, the caching framework will take care of this for you.

Hibernate 4 + Spring 3.2 + Transaction : One Service, Several Dao , One Method

I'm a beginner in hibernate 4 & Spring 3.2 stuffs.
I have read some tutorials and discussion on stack but i don't find a clear answer to my questions. And i think the best way to understand is to ask and share knowledges !
Here we go!
So you create each time a Pojo, a Dao , a Service class, with methods annotated transactionnal. That's ok. I'm using Sessionfactory to handle my transaction. I'm looking for good practices.
1- If you want to use Delete Method and Save Method from the same Service, how will you do to make it works in a same transaction. When i look at the log, each method are executed in different transactions.
This SampleServiceImpl:
#Transactional
public void save(Sample sample){
sampleDao.save(sample);
}
#Transactional
public void delete(Sample sample){
sampleDao.delete(sample);
}
// A solution could be that , but not very clean...there should be an another way, no?
#Transactional
public void action(Sample sample){
sampleDao.save(sample);
sampleDao.delete(sample);
}
2- If you want to use Delete Method and Save Method from different Services class, how will you do to make it works in a same transaction. Because each method in each service class is handled by a Transactionnal annotation. Do you create a global Service calling all subservice in one method annoted Transactional
SampleServiceImpl:
#Transactional
public void save(Sample sample){
sampleDao.save(sample);
}
ParcicipantServiceImpl
#Transactional
public void save(Participant participant){
participantDao.save(participant);
}
// A solution could be that , but not very clean...there should be an another way, no?
GlobalServiceImpl
#Transactional
public void save(Participant participant,Sample sample){
participantDao.save(participant);
sampleDao.save(sample);
}
3- And the last question but not the least .If you want to use several Methods from severals service in one global transaction. Imagine you want to fill up 5 or more table in one execution of a standalone program. How is it possible because each Service to have his proper transactional method, so each time you called this method, there is a transaction.
a- I have successfully arrive to fill up two tables in a sample transaction using Mkyong tutorial and cascade property in the mapping. So i see how to make it works for one table directly joined to one another or more tables.
b- But if you have a 3 tables Participant -> Samples -> Derived Products. How will you fill up the three tables in a same transaction.
I don't know if i'm clear. But i would appreciated some help or example on that from advanced users.
Thanks a lot for you time.
Your solution is fine, maybe this works if you want to using nested transactional methods(note I saw this solution couple days ago and didn't test it):
< tx:annotation-driven mode="aspectj" / >
< context:load-time-weaver aspectj-weaving="on"/ >
#Transactional
public void action(Sample sample){
save(sample);
delete(sample);
}
Transaction should propagate.
GlobalServiceImpl
#Transactional
public void save(Participant participant,Sample sample){
participantDao.save(participant);
sampleServiceImpl.save(sample);
}
The approch you are following is cleaner approch,
ServiceOpjects are ment to contain business logic. Hence they will always manuplate through data objects.
What we do in practise is create a another layer that uses dataObjects and and other functional call of same layer. Then this all business layer is called via service layer having annotation #transactional.
Can you please mention why you think this approch is dirty??

Spring MVC #Cacheable annotation on Generic Method

I am using spring MVC with Hibernate
Generic Method
// getAllById
#SuppressWarnings("unchecked")
public <T> List<T> getAllById(Class<T> entityClass, long id)
throws DataAccessException {
Criteria criteria = sessionFactory.getCurrentSession().createCriteria(entityClass)
.add(Restrictions.eq("id", id));
return criteria.list();
}
In controller
List<GenCurrencyModel> currencyList=pt.getAllById(GenCurrencyModel.class,1);
Question
How we can use #Cacheable("abc") annotation in Generic method and destroy the cache on demand using spring mvc + hibernate with generic DAO
According to the example in spring doc it specify annotation on simple method !
#Cacheable("books")
public Book findBook(ISBN isbn) {...}
I actually required, when Id pass to generic method ,it should first look up in cache, and I should also destroy cache on demand !
First of all think about the implications of using Generics for a moment:
You don't know which types you will use in the future. You don't know the cache names either for that matter.
You (may) have no type information, so there is no chance of choosing a specific cache.
The last point can be solved by always providing type information, like entityClass in your method.
Solution 1: One cache
Use one cache and generate a key based on the type.
#Cacheable(value="myCache", key="#entityClass.name + #id")
Solution 2: Use #Caching
While you can use expressions for the key you can't use them for the cache names. #Caching allows you to use multiple #Cachable annotations, each with another cache name.
#Caching (
#Cacheable(value="books", key="#id", condition="#entityClass.name == 'Book'"),
#Cacheable(value="students", key="#id", condition="#entityClass.name == 'Student')
)
Solution 3: Write your own cache provider
This is not much of an effort to do. The Spring default cache provider is just a map after all. Your implementation could use different 'subcaches' for each type.
Clearing the cache is more difficult. The solutions 1 and 3 have only one cache. You cannot clear only 'books' but not 'students'. Solution 2 has that option but you have to provide all possible caches and types.
You could use solution 3 and talk to the cache directly instead of using #CacheEvict.

#Cacheable with Spring 3.1

I am using #Cacheable with Spring 3.1. I little bit confused with value and key mapping parameters in Cacheable.
Here is what I am doing:
#Cacheable(value = "message", key = "#zoneMastNo")
public List<Option> getAreaNameOptionList(String local, Long zoneMastNo) {
//..code to fetch data form database..
return list;
}
#Cacheable(value = "message", key = "#areaMastNo")
public List<Option> getLocalityNameOptionList(String local, Long areaMastNo) {
//..code to fetch data form database..
return list;
}
What happening here, second method is dependent on selected value of first method,
but issue is suppose when I pass zoneMastNo = 1 and areaMastNo = 1 then second method returns first methods result.
Actually, I have lots of services hence, I am looking to use common value for cacheable for specific use cases.
Now my questions are:
How can I solve this issue?
Is it good idea that use cacheable for every services?
After specified time will cache completely remove from memory without
using #CacheEvict ?
How can I solve this issue?
I assume zoneMastNo and areaMastNo are completely different keys, by which I mean List<Option> for zoneMastNo = 1 is not the same as List<Option> for areaMastNo = 1. This means you need two caches - one keyed by zone and the other by area. However you are explicitly using only one cache named message. Quoting 29.3.1 #Cacheable annotation:
#Cacheable("books")
public Book findBook(ISBN isbn) {...}
In the snippet above, the method findBook is associated with the cache named books.
So if I understand correctly, you should basically use two different caches:
#Cacheable(value = "byZone", key = "#zoneMastNo")
public List<Option> getAreaNameOptionList(String local, Long zoneMastNo)
//...
#Cacheable(value = "byArea", key = "#areaMastNo")
public List<Option> getLocalityNameOptionList(String local, Long areaMastNo)
Also are you sure these methods won't have a different result depending on local parameter? If not, what is it used for?
Is it good idea that use cacheable for every services?
No, for the following reasons:
some methods are just fast enough
...and caching introduced some overhead on its own
some services call other services, do you need caching on every level of hierarchy
caching needs memory, a lot of it
cache invalidation is hard
After specified time will cache completely remove from memory without using #CacheEvict ?
That totally depends on your cache implementation. But every sane implementation has such an option, e.g. EhCache.
question 3:
it depends on your cache expiration configuration. if you use ehcache, change the settings in ehcache.xml.

EhCache: #CacheEvict on Multiple Objects Using Annotations

I understand that using Spring's (3.1) built in CacheManager using the EhCache implementation, there are certain limitations when in proxy mode (the default) as per this post:
Spring 3.1 #Cacheable - method still executed
Consider the scenario I have:
#CacheEvict(value = "tacos", key = "#tacoId", beforeInvocation = true)
removeTaco(String tacoId) {
// Code to remove taco
}
removeTacos(Set<String> tacoIds) {
for (String tacoId : tacoIds) {
removeTaco(tacoId);
}
}
In this repository method, calling removeTacos(tacoIds) will not actually Evict anything from the Cache because of the limitation described above. My workaround, is that on a service layer above, if I wanted to delete multiple tacos, I'd be looping through each taco Id and passing it into removeTaco(), and never using removeTacos()
However, I'm wondering if there's another way to accomplish this.
1) Is there an SpEL expression that I could pass into the key that would tell EhCache to expire every id in the Set?
e.g. #CacheEvict(value = "tacos", key = "#ids.?[*]") // I know this isn't valid, just can't find the expression.
Or is there a way I can have removeTacos() call removeTaco and actually expire the Cached objects?
The #Caching annotation can be used to combine multiple annotations of the same type such as #CacheEvict or #CachePut, this is the example from the Spring documentation
#Caching(evict = { #CacheEvict("primary"), #CacheEvict(value="secondary", key="#p0") })
public Book importBooks(String deposit, Date date)
You can do one of two things
#CacheEvict(value = "tacos", allEntries = true)
removeTacos(Set<String> tacoIds)
which is not so bad if tacos are read a lot more than they are removed
OR
removeTacos(Set<String> tacoIds) {
for (String tacoId : tacoIds) {
getTacoService().removeTaco(tacoId);
}
}
by calling the service (proxy) you invoke the cache eviction.
AFAIK #CacheEvict supports only removing single entry (by key) or all entries in given cache, there's no way to remove at once multiple entries. If you want to put, update or remove multiple objects from cache (using annotations) and you may switch to memcached take a look at my project Simple Spring Memcached (SSM).
Self invocations don't go through the proxy so one of the solution is to switch to other mode than proxy. Anther solution (I'm not recommending it) may be keeping reference to the service in service (as an autowired field) and use it to invoke removeTaco.
Several months ago I had similar issue in one of my projects. It didn't use Spring Cache but SSM which also requires proxy. To made it work I moved caching (annotations) from service to DAO (repositories) layer. It solved problem with self invocation.

Resources