This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Packaging webapp and transaction creation

Oct 1st, 2012, 09:39 AM

When I package my classes into WEB-INF/classes the Spring @Transactional methods (or any of the methods that match the point-cut definition) that I have do not take part in a transaction. I am met with lots of 'No Hibernate session found, configuration does not allow...' exceptions in the logs. The puzzling thing is that in the stack trace I can see the CGLIB enhanced class so it does appear to be proxied but a new transaction does not seem to be created.

However if I package the same classes into a jar file and place the jar in WEB-INF/lib, the application works fine! The transaction is created etc., Whats going on here?!? Why doesn't it work when the classes are under WEB-INF/classes?

But when the time comes to actually work in the transactional method, it explodes with exception about not being allowed to create transaction.

Code:

org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here]
at org.quartz.core.JobRunShell.run(JobRunShell.java:227)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549)
Caused by: org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
at org.springframework.orm.hibernate3.SpringSessionContext.currentSession(SpringSessionContext.java:63)
at org.hibernate.impl.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:698)

For starters what on earth are you trying to do?! Your tx:advice and aop:config are useless as you want to use @Transactional (it is either that or your @Transactional/tx:annotation-driven is useless). So basically what you see in the logging is junk as that isn't being used.

Your stacktrace indicates that you are trying to do something with quartz which at times is trouble some.

Also you are using component-scanning and as you havea web application I assume you have both a ContextLoaderListener and a DispatcherServlet. Make sure you don't scan the same component twice (i.e. component-scan in both the CLL and DS scanning the same package).

Comment

For starters what on earth are you trying to do?! Your tx:advice and aop:config are useless as you want to use @Transactional (it is either that or your @Transactional/tx:annotation-driven is useless). So basically what you see in the logging is junk as that isn't being used.

Only one of them (the tx:advice or the tx:annotation-scanning) can be used in an application context? I removed the tx:annotation-driven (as of now I do not have any methods annotated with @Transactional) and just relied on tx:advice and the aop:config to do their thing but the problem still persists.

Your stacktrace indicates that you are trying to do something with quartz which at times is trouble some.

Can you please elaborate?

Also you are using component-scanning and as you havea web application I assume you have both a ContextLoaderListener and a DispatcherServlet. Make sure you don't scan the same component twice (i.e. component-scan in both the CLL and DS scanning the same package).

Only one of them (the tx:advice or the tx:annotation-scanning) can be used in an application context? I removed the tx:annotation-driven (as of now I do not have any methods annotated with @Transactional) and just relied on tx:advice and the aop:config to do their thing but the problem still persists.

No you can use them together but in general when using @Transactional (which according to your starting post is what you used) adding a tx:advice with aop:config is overkill and might lead to duplicate proxies.

Can you please elaborate?

Without the full stacktrace that is quite hard, but depending on your configuration it can be that quartz uses an unproxied instance of your bean...