We Keep Coding

What's the role of spring boot cache annotations in a application which use Redis for caching?

I am using Redis as the in-memory data store for caching purposes in my spring boot application. At the moment I have already implemented the Redis support with basic CRUD functionalities for the entities which I need to cache [Scenario 1] . But suddenly I found that there are lots of resources out there that use additional spring boot caching annotations like #Cachable #CahceEvict to implement the caching with Redis [Scenario 2] . And I monitored that when we start using those annotations in an operation like find(params) only the first method call will be going to the Redis. From the second method onwards, Redis won't get hit. So according to my observations, I think, Spring boot maintains a separate cache. But my problem is we are already using Redis as our cache. So what's the advantage of stopping the second Redis data store hit and maintaining another cache. I mean Redis is already in the RAM and it's highly capable of caching. Why do we need to maintain two caches? Is there any advantage of having this mechanism or does implement the Redis only is enough ?.
Scenario 1 :
public class RestController{
#GetMapping("/{id}")
public Product findProductById(#PathVariable int Id){
return dao.findProductById(id);
}
}
#Repository
public class ProductDao {
public static final String HASH_KEY = "Product";
#Autowired
private RedisTemplate template;
public Product findProductById(int id){
return (Product) template.opsForHash().get(HASH_KEY,id);
}
}
Scenario 2 :
public class RestController{
#GetMapping("/{id}")
#Cachable(key = "#id" ,value="Product")
public Product findProductById(#PathVariable int Id){
return dao.findProductById(id);
}
}
#Repository
public class ProductDao {
public static final String HASH_KEY = "Product";
#Autowired
private RedisTemplate template;
public Product findProductById(int id){
System.out.println("called findProductById() from DB");//Here only for the first time method will be called
return (Product) template.opsForHash().get(HASH_KEY,id);
}
}
References for Scenario 1 implementation
References for Scenario 2 implementation

The Spring Cache abstraction provides a cache abstraction layer you can configure to support different, pluggable, underlying cache mechanisms, Redis through Spring Data among others.
You are using Redis as the actual persistence mechanism. As a consequence, probably you do not need any cache and, due to the in-memory nature of the Redis database, the scenario 1 can be appropriate.
Having said that, please, consider a different point of view.
Let's consider for example a backend that uses a persistence layer with an underlying not in-memory database, relational or other flavor of NoSQL.
This is a perfect use case for Spring Cache, #Cacheable and the rest of related annotations to effectively cache your results.
And, how Redis fits in to this puzzle? Because you configure Spring to use Redis as the actual cache manager. For example:
#Bean
public RedisCacheManager cacheManager(RedisConnectionFactory connectionFactory) {
return RedisCacheManager.create(connectionFactory);
}
Under the hood RedisCacheManager will provide the necessary mechanisms to transparently write and read from Redis as required by the application cache.
With this new point of view, the scenario 2, with the above-mentioned differences, is the one to choose and in fact is a common scenario you usually find when architecting enterprise applications.
In any case, the scenario 2 as described in your question, I mean, using Redis directly as the persistence mechanism in addition to Spring Cache, can be also applicable if you are trying:
Reducing the number of requests - and associated costs - performed against Redis. This could be relevant especially if you are using Redis (or a Redis-like service such as GCP Memorystore) in a cloud provider.
Despite the fact that Redis is fast enough, you can use a cache to store the results in the local RAM of the machine running your application to improve performance, just like with any other database system.
Or because you need to interact with Redis in some specific way.
If you are using Redis only for caching and do not require any specific stuff, probably it would be preferable to use it through the Spring Cache abstraction instead of manually perform the cache operations: it will provide no performance benefit, but you will get a several advantages like a well structured cache framework, with a set of helpful annotations, and portability/usability because you can switch the cache implementation only using a different configuration if required, for testing or local development, for example.

Wildfly treating concurrency management as transactional

I had a class that looked like this:
#Singleton
#ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)
#Lock(LockType.WRITE)
#AccessTimeout(value = 20, unit = TimeUnit.MINUTES)
public class MyClass{
public void someLongRunningQuery(){
}
}
However, this would fail with:
org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
I was able to resolve this by adding this annotation.
#TransactionTimeout(value = 20, unit = TimeUnit.MINUTES)
My question is - why is jboss treating this method as a transaction? My understanding is the concurrency management and transaction management are different things.

Transaction timeout handling is not defined in EJB spec and JBoss uses a separate transaction management module to do that. Your example points at a REST access to your singleton - is the Singleton also a REST endpoint or is it invoked from some REST endpoint bean? Just a couple of ideas:
If you have a REST endpoint that injects your singleton and invokes the long running op, isn't it by any chance a #Stateless bean? EJB beans are transaction enabled by default, therefore if a client(REST endpoint) initiates a transaction(it does by default - #TransactionAttribute(REQUIRED)), your singleton will also participate in the same transaction, but because its invocation takes longer than the default transaction timeout value(300s) it causes transaction rollback. If you do not need a transaction on the rest layer, try disabling it with #TransactionAttribute(NOT_SUPPORTED)
If you invoke this long running op from REST layer, wouldn't it be better to use #Asynchronous and return some kind of request/job handle to the client, so that it can query the status of the operation instead of waiting and blocking while it finishes? Keep in mind that EJBs are pooled resources, therefore invoking this long op multiple times can drain your pool and cause acquisition timeouts.

Transaction Management in Spring Data REST

Do we have any in-built transaction management when using Spring Data REST or it has to be manually maintained/handled from the calling application/service.
Say, I have two calls(first POST(for creation) and PATCH(update/insert association resource using uri-lists)) which I want to be considered as a transaction.
Thanks
Bharath

In spring data rest every repository action runs within a transaction. Even the event handlers are not running inside the repository transaction. And of course different actions on the REST API do run in separate transactions.
Here is an interesting question on this topic:
Handle spring-data-rest application events within the transaction
If you want to have creation and association in one transaction then the only way to achieve this with your current entity mapping is to create a custom controller that does just that.
An alternative mapping strategy would be to treat the associated entity as a containment - so the associated entity does not have an exported repository and is maintained within the parent.

The who point of REST is to have isolated units of work. If you are wanting to keep transactions open across calls it's probably a sign you need to adjust your RESTful strategy.
Have a look at: Transaction strategy for microservices

I found this question when researching the transaction behavior of data-rest.
I needed control over the transaction behavior of the default controllers, especially during serialization of relationships, so i could mark transactions as read-only and route them to read-replicas of our database.
By default every call to a repository has its own transaction and database access during events or resource-assembly is managed by hibernate directly, outside of these transactions. There is no intended way for users to control transactions.
Spring does however provide methods to do that using aop-interceptors. These interceptors use a property source do decide weather or not a method requires a transaction. Springs own Transactional-Annotation is nothing more than one of these property-sources.
The following Configuration creates an advisor for the default rest-controllers that creates customized transactions for some Methods:
#Configuration
#ConditionalOnClass(name = {
"org.springframework.data.rest.webmvc.RepositoryEntityController",
"org.springframework.data.rest.webmvc.RepositoryPropertyReferenceController",
"org.springframework.data.rest.webmvc.RepositorySearchController"
})
public class RepositoryRestControllerTransactionConfiguration {
/**
* A custom Transaction Advisor that starts customized transactions based on what data-rest controller method is called
*
* #param transactionManager
* #return
*/
#Bean
public BeanFactoryTransactionAttributeSourceAdvisor transactionAdvisor(
TransactionManager transactionManager) {
//Specify transaction management methods and attribute values required for transaction control
MethodMapTransactionAttributeSource source = new MethodMapTransactionAttributeSource();
Map<String, TransactionAttribute> methodMap = new HashMap<>();
// methods are identified by their FQDN, simple placeholders using * are possible
// methods that should only require reads
methodMap.put("org.springframework.data.rest.webmvc.RepositoryEntityController.get*", createTransactionRule(true));
methodMap.put("org.springframework.data.rest.webmvc.RepositoryEntityController.headForItemResource", createTransactionRule(true));
methodMap.put("org.springframework.data.rest.webmvc.RepositoryPropertyReferenceController.follow*", createTransactionRule(true));
methodMap.put("org.springframework.data.rest.webmvc.RepositorySearchController.execute*", createTransactionRule(true));
// methods that will require write
methodMap.put("org.springframework.data.rest.webmvc.RepositoryEntityController.put*", createTransactionRule(false));
methodMap.put("org.springframework.data.rest.webmvc.RepositoryEntityController.patch*", createTransactionRule(false));
methodMap.put("org.springframework.data.rest.webmvc.RepositoryEntityController.delete*", createTransactionRule(false));
methodMap.put("org.springframework.data.rest.webmvc.RepositoryEntityController.post*", createTransactionRule(false));
methodMap.put("org.springframework.data.rest.webmvc.RepositoryPropertyReferenceController.delete*", createTransactionRule(false));
methodMap.put("org.springframework.data.rest.webmvc.RepositoryPropertyReferenceController.create*", createTransactionRule(false));
source.setMethodMap(methodMap);
source.afterPropertiesSet();
// Generate an AOP Advisor that controls transactions
// Advice for transaction control (TransactionInteceptor)
BeanFactoryTransactionAttributeSourceAdvisor advisor = new BeanFactoryTransactionAttributeSourceAdvisor();
advisor.setTransactionAttributeSource(source);
advisor.setAdvice(new TransactionInterceptor(transactionManager, source));
return advisor;
}
private RuleBasedTransactionAttribute createTransactionRule(boolean readOnly) {
RuleBasedTransactionAttribute rule = new RuleBasedTransactionAttribute();
rule.setReadOnly(readOnly);
return rule;
}
}

Will Spring estabilish connection to DB, when I use transacional bean in non-transacional?

Good day, guys!
If I have non-transactional bean(BannerSizeServiceUntransact), which uses transactional bean(bannerSizeService), will Spring estabilish connection to DB, when I use non-transacional bean?
(I have many refused connections to PostgreSQL in log. I belive my logic does;t create new connection on each request, but may be I wrong.)
#Repository
public class BannerSizeServiceUntransactImpl implements BannerSizeServiceUntransact {
#Resource
BannerSizeService bannerSizeService;
public List<BannerSizeVO> sizesByType(String type) throws BannerServiceException{
return bannerSizeService.sizesByType(type);
} }
#Repository
#Transactional
public class BannerSizeServiceImpl implements BannerSizeService {
....
}

Yes, Spring will establish a database connection even when you're using beans that aren't marked #Transactional, so that's not the cause of your refused connections.
What's going to happen in this scenario is that when you invoke the call to bannerSizeService.sizesByType(type), Spring will start a new transaction, and when control returns to BannerSizeServiceUntransact.sizesByType(), it will end. So if BannerSizeServiceUntransact.sizesByType() did other database calls before or after the call to bannerSizeService.sizesByType(type), those calls would happen in separate transactions, one per DB call. (Not annotating a Service as #Transactional doesn't mean that transactions aren't used, just that they only span a single database call.)
Also note that if the method that calls BannerSizeServiceUntransact.sizesByType() was marked #Transactional, then the transaction started there will carry over all of the code you've shown here, because that transaction will start when that higher-up method is called and will end when it ends, and all of the code here will have executed while it was in effect. Not annotating something as #Transactional doesn't forbid its participation in an existing transaction, it just doesn't require the initiation of a new one.
Also, keep in mind that #Transactional controls transactions. Spring might end up making a new connection for each transaction it opens, or using only one and reusing it for each transaction, or rotating through a pool of connections (resulting in more than one but fewer than N connections for N transactions). It's guaranteed that if Spring talks to the database, there will be a connection in use, but you can't guarantee how many will be used over N calls simply by your #Transactional annotations. (Though of course you can set settings in your Spring config that might impact the number used, e.g. specifying a connection pool with a max size of 1.)

Seeking a Spring (3.0.5) Solution for: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here

I have a Transaction problem on Spring 3.0.5. In my case I get the so-called exception "No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here"... I have tried everything so far. I can see in my log that the transactional services are detected and registered as Spring beans and I can also see in the logs that they are proxied and associated with underlying Spring transaction interceptors. (Advise) When I run my Spring MVC app my controller will call the service...... :-( but the transaction interceptors are not triggered. (??) I expect my Spring service proxy to open a session and start a transaction before calling my target service method. Since this does not happen, I get the above exception. I have been almost two days on this problem. Tried everything which I found on the internet...but in vain.
I have layered architecture: presentation (springmvc), service (transaction annotated), dataacess (Spring/Hibernate classic sessionfactory). My model objects are annotated with jpa (javax.persistence.*). My spring context config files are separated in appContext.xml, appContext-service.xml and appContext-dao.xml. I have defined my Spring LocalSessionFactoryBean, Datasource and TransactionManager (HibernateTransactionManager) in appContext-dao.xml. I have put in appContext-service.xml where my service implementations resides. In all of my config files I have included and to detect my beans through Controller, Service and Repository annotations.
I appreciate any kind of help.

It sounds like you are doing everything correctly and you know what you are doing. There's not much we can do here unless you show some configuration.
What I'd suggest is some debugging.
First: do you have Unit tests in the service layer that test the queries you are using? Perhaps you can find the error in the service layer.
Then: debug the MVC app, check the types of the injected services. Verify that they are proxies, not the original types.
If they are the original types, you
have an error in your transaction
configuration .
If they are proxies, step through the
query methods and verify that the
transaction logic is applied.

This sounds like accessing a lazily-loaded list or set of you dao after the closing of the transaction. This typically happens if you access that list in the view in stead of the controller, as your controller probably calls methods in transaction scope, and then leaves the transaction and forwards the loaded bean to the view.
Simple solutions:
Configure your data bean to eagerly load
Force loading of the dependencies in the controller (just loop through them)
have a look at this article ans possibly also quite a few right here on SO on lazy loading / lazy fetching of one-to-many associations and the like
Imagine:
// your dao
public class Foo {
// lots of other properties
List<Something> stuff;
// getters and setter for stuff
}
// repository
#Transactional
public class FooRepo {
public Foo loadFoo(int id) {
...
}
}
// Controller
public class Controller {
public void Control() {
sessionContext.set("foo", repo.loadFoo(1)); // transaction managed by spring
}
public void setFooRepo(FooRepo repo) {this.repo = repo};
}
// View
for (Something something : foo.getStuff()) {
// Ooops transaction is closed! stuff is lazily loaded so NOT AVAILABLE
// practical solutions:
// - do not load lazily (Foo.hbm.xml)
// - or force loading by getting all Somethings in the controller
}