Why am I posting this?
After several hours of search / analysis / getting paranoid I would like to share my fault with you - I nailed down my cause of the problem.
When did it happen?
within the application server (in my case embedded tomcat) - tests had no problem
on two specific #Services on which the methods got properly annotated with #Transactional
What was not the problem?
Missing #EnableTransactionManagement in the #Configuration
Some weired AOP issue, eg having no default constructor in a Service not implementing an interface (AFAIK this problem does not exist anymore since Spring 4.0)
What was the problem?
I am using a CustomPermisionEvaluator for Security eg for securing methods like this:
#RequestMapping(value = "/{name}", method = RequestMethod.GET)
#PreAuthorize("hasPermission(null, 'SERVICE.ASSOCIATION.FIND_BY_NAME')")
public ResponseEntity<AssociationResult> findByName(#PathVariable String name) {
//do stuff
}
For doing this I have to extend the GlobalMethodSecurityConfiguration to get my CustomPermissionEvaluator into business. In there I used #Autowiring to get access to the beans needed for the permission evaluation. And guess what - this were those 2 #Services which the TransactionInterceptor ignored.
tl;dr
Do not autowire beans into GlobalMethodSecurityConfiguration => they will not get intercepted properly afterwards.
Related
I have an old controller within my app that is defined as a spring bean in xml and makes use of Spring's SimpleFormController. I've tried to make the processes within the onSubmit method of the controller transactional by adding the #Transactional annotation but it doesn't work. According to this guide the invocation of the annotation must happen "outside of the bean", does this mean that the annotation cannot be used in old Spring controllers like mine? Are there any alternatives or workarounds?
The reason I know it's not working is because 1) changes to the db are not rolled back on error (this is despite the fact that I have defined rollbackFor = Exception.class, and even in some instances used TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();, in this instances where it tries to use the latter it throws an error stating there is no transaction present. 2) I've added breakpoints to where #Transactional is instantiated within Spring and none of them get hit.
EDIT: So people are asking for reproducible examples of code. The problem doesn't lie within the business logic code, I'm looking for clarity on the usage of the annotation within a Spring 2 controller. So what I have for example is this:
public class ImportController extends SimpleFormController {
#Override
#Transactional(rollbackFor = Exception.class)
public ModelAndView onSubmit(HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception {
...
}
}
You are right. #Transactional will not work here because onSubmit is invoked by the same bean.
And in this case the call is done directly and the default spring transaction handling does not work.
See answers in this question for a detailed explanation of the options you have
So, I have an application running on WildFly10, which uses JSF, Spring (DI), JPA, Spring Data;
Right now we're trying to move it to CDI and remove Spring(DI). For now we'll keep Spring Data.
So, I set up CDI and made an EntityManager producer.
#Produces
#Dependent
#PersistenceContext
public EntityManager entityManager;
So, I'm able to inject repositories with CDI and all.
However on my original environment we had a custom repository factory,that was defined in my SpringConfiguration like this:
#EnableJpaRepositories(basePackages = {"com.foo.repository" }, repositoryFactoryBeanClass=CustomJpaRepositoryFactoryBean.class)
So, the question is, how can I define this repositoryFactoryBeanClass=CustomJpaRepositoryFactoryBean.class on a CDI environment?
The current implementation doesn't allow the configuration of the JpaRepositoryFactoryBean as one can see from the code where it gets instantiated.
So I guess you have the following options:
reimplement the instantiation process.
open a feature request.
do 2. and 1. in a reusable way and submit the result as a PR for the issue.
When trying to solve this problem I found that the custom impl was not being picked up. The solution suggested in this question helped me however: https://stackoverflow.com/a/38541669/188624
Basically is uses Java8 default interface method to provide the additional functionality. I had to use the "CDI.current().select" method to get hold of the entity manager though as property injection of course won't work.
I tested with Spring Data JPA 2.0.0
After I added #Retryable annotation to my spring-data-cassandra repository interface, now the application fails to start with following exception:
APPLICATION FAILED TO START
The bean 'airingDao' could not be injected as a 'my.dao.AiringDao' because it is a JDK dynamic proxy that implements:
org.springframework.data.cassandra.repository.CassandraRepository
Action:
Consider injecting the bean as one of its interfaces or forcing the use of CGLib-based proxies by setting proxyTargetClass=true on #EnableAsync and/or #EnableCaching.
Added proxyTargetClass=true to #EnableAsync and #EnableCaching, even to #EnableRetry(proxyTargetClass = true)
#EnableAspectJAutoProxy(proxyTargetClass = true)
But still doesn't work.
After I remove the #Retryable, every thing works fine.
Checked the code, without #Retryable, in org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(String, Class<T>, Object[], boolean)
bean.getClass().getInterfaces()
(java.lang.Class<T>[]) [interface my.dao.AiringDao, interface
org.springframework.data.repository.Repository, interface
org.springframework.transaction.interceptor.TransactionalProxy, interface
org.springframework.aop.framework.Advised, interface
org.springframework.core.DecoratingProxy]
So requiredType.isAssignableFrom(bean.getClass()) is true
But after added #Retryable:
bean.getClass().getInterfaces()
(java.lang.Class<T>[]) [interface
org.springframework.retry.interceptor.Retryable, interface
org.springframework.aop.SpringProxy, interface
org.springframework.aop.framework.Advised, interface
org.springframework.core.DecoratingProxy]
So now requiredType.isAssignableFrom(bean.getClass())) is false and getTypeConverter().convertIfNecessary(bean, requiredType) throws the exception.
Could anyone please help or provide some clue how to troubleshoot it?
Thanks for your help.
Don't know Spring Retry, and haven't checked in detail, but I suspect, that there is no integration between Spring Data and Spring Retry yet. If this is true, you have two approaches available to you:
Open an issue on Spring Data or Spring Retry to get the integration implemented.
Introduce a separate layer for you #Retry which you then let delegate to your Spring Data repositories.
Of course those approaches aren't mutual exclusive.
Here is a workaround provided. I raised an issue for this in Spring-Retry GitHub.
Spring-Retry Github Issue
I have the following problem:
I'm using Spring MVC 4.0.5 with Hibernate 4.3.5 and I'm trying to create a Restfull Web application. The problem is that I want to exclude some fields from getting serialized as JSON, depending on the method called in the controller using aspects.
My problem now is that Hiberate does not commit the transaction immideatly after it returns from a method but just before serializing.
Controller.java
public class LoginController {
/*
* Autowire all the Services and stuff..
*/
#RemoveAttribues({"fieldA","fieldB"})
#RequestMapping{....}
public ResponseEntity login(#RequestBody user) {
User updatedUser = userService.loginTheUser(user);
return new ResponseEntity<>(updatedUser,HttpStatus.OK);
}
}
Service.java
public class UserService {
#Transactional
public User loginUser(User user) {
user.setLoginToken("some generated token");
return userDao.update(user); //userDao just calls entityManager.merge(..)
}
}
The advice of the aspect does the following:
for every String find the corresponding setter and set the field to null
This is done, like I said, to avoid serialization of data (for which Jackson 2 is used)
The problem now is that only after the advice has finished the transaction is commited. Is there anything I can do to tell hibernate to commit immediatly or do I have to dig deeper and start handling the transactions myself (which I would like to avoid)?
EDIT:
I also have autocommit turned on
<prop key="hibernate.connection.autocommit">true</prop>
I think the problem lies in the fact that I use lazy loading (because each user may have a huge laod of other enities attached to him), so the transaction is not commited until I try to serialze the object.
Don't set auto-commit to true. It's a terrible mistake.
I think you need a UserService interface and a UserServiceImpl for the interface implementation. Whatever you now have in the UserService class must be migrated to UserServiceImpl instead.
This can ensure that the #Transactions are applied even for JDK dynamic proxies and not just for CGLIB runtime proxies.
If you are using Open-Session-in-View anti-patterns, you need to let it go and use session-per-request instead. It's much more scalable and it forces you to handle optimum queries sin your data layer.
Using JDBC Transaction Management and the default session-close-on-request pattern you should be fine with this issue.
I noticed that the following is not working in a class marked as a #Controller:
#Autowired
SessionFactory sessionFactory;
#ResponseBody
#Transactional
#RequestMapping(method = RequestMethod.GET , value = "/map")
public ArrayList<PhotoDTO> getPhotos(...someParams) {
Entity result sessionFactory.getCurrentSession()... //do some manipulation
return result;
}
when I call the URL, I get an error saying that the method is not transactional (although, as you can see, it is marked as one)
If I copy this method to a another class called MyService and call it from the controller instead, it works perfectly
Is this some sort of a Spring advice (a conspiracy to make me use more classes more or less)?
Don't do transactions in your controller. Put them in your service layer classes.
Separate your code into model-view-controller.
Yes it is a conspiracy. It enables to you to share code between controllers/views without repeating code. And also stops rollbacks of transactions unnecessarily (for exceptions unrelated to the actual transaction).
It might seem like more code to begin with, but in the long run it is much more manageable and simpler to develop.
Probably you have two application contexts here: main Spring context loaded by ContextLoaderListener and a child context loaded by DispatcherServlet. You need to put <tx:annotation-driven /> in the configuration loaded by the child context too. If you show us your web.xml file maybe I can help you more.
Anyway, as #NimChimpsky says, is usually not a good practice to manage transactions in your controller layer.