I've searched for a long time on this topic however I cannot find a solution to my specific issue. I am trying to figure out how I can pull the JDBC connection from Hibernate so that I can run a query for generating reports. I am trying to use a JDBC connection since my reports don't map well to the existing Entity situation that we have.
Right now, my application has a bean for a LocalContainerEntityManagerFactoryBean and a bean for DataSource, which is a just a DriverManagerDataSource, both residing in a core configuration file. The problem that I am having is, whenever I try to wire up my DAO to access the JDBC connection by doing something like this:
#PersistenceContext
private EntityManagerFactory entityManagerFactory;
private SessionFactory session;
public SystemUsageReportDAO() {
session = entityManagerFactory.unwrap(SessionFactory.class);
}
I simply get a null pointer exception at the constructor line. I've tried all manner of getting the connection from the EntityManagerFactory, however I'm not sure how I can do it. Any advice would be appreciated.
I know that my end goal is to get a Session object, and from there I can call doWork, however getting to that Session is proving quite the task for me.
Related
I'm facing an "Too many clients" error when using jooq in my spring boot application.
Currently I'm autowiring my DSLContext and was hoping that jooq auto closes the connections to my postgres, which apparently does not work properly.
Is there a way of releasing the connection manually?
#Autowired
lateinit var dsl: DSLContext
//further down
dsl.close() //didn't help
I found ideas which suggest to do something like this (Java code but you get the point ;) ),
but i would like to stick with the idea of autowiring the DSLContext (like above) and not the DataSource itself:
#Autowired
private DataSource dataSource;
//Further down
Connection con=dataSource.getConnection();
DSLContext create = DSL.using(con, SQLDialect.MYSQL);
//Execute code here
con.close();
There are probably control flows that lead to your con.close() call being skipped. However, you don't have to do the connection management manually with jOOQ. Just pass the DataSource to your DSL.using() call instead:
#Autowired
private DataSource dataSource;
//Further down
DSLContext create = DSL.using(dataSource, SQLDialect.MYSQL);
In our project we use Spring and Spring Data (for server side API service), but sometimes we do query not using Spring Data, but using JPA criteria. In order to do so we use:
#PersistenceContext
private EntityManager em;
...
CriteriaBuilder cb = em.getCriteriaBuilder();
...
From the Spring docs:
Although EntityManagerFactory instances are thread-safe, EntityManager instances are not. The injected JPA EntityManager behaves like an EntityManager fetched from an application server's JNDI environment, as defined by the JPA specification. It delegates all calls to the current transactional EntityManager, if any; otherwise, it falls back to a newly created EntityManager per operation, in effect making its usage thread-safe.
So it seems that the way we use should get the current session if exists and if not should create new one. The issue we are facing is a memory leak of this use. seems like this way opens a lot of Hibernate session and does not close them.
So for the question: What is the best practice to getCurrent/open new session in Spring with Hibernate?
Note: HibernateUtil does not have getSessionFactory() as suggested in some other posts
Thanks,
Alon
I have a list of Transaction objects.
List<Transaction> transactions;
I need to batch process these transactions by creating a pool of threads which update transactions concurrently.
These threads update these transactions using the same DAO class(Spring singleton bean) to update the transaction. I'm using Hibernate as ORM
What am I to consider to make sure my code is thread safe? I'm a bit confused.
Here's the DAO class. SessionFactory is also defined as a Spring bean which is then autowired to DAO class.
#Autowired
SessionFactory sessionFactory;
#Override
public Transaction update(Transaction transaction) {
Session session = sessionFactory.openSession();
session.beginTransaction();
session.update(transaction);
session.getTransaction().commit();
return transaction;
}
To get much better performance look at pooling the DB connections, there are open source implementations like c3p0 which works nicely with spring and hibernate. This is particularly import for batch processing.
Are you using the hibernate implementation of SessionFactory? If that is the case then it is indeed thread safe so you should be good.
Another suggestion is to look at spring batch which might be useful for your situation.
Update: you've already said you are using Hibernate so the SessionFactory should be good.
I think your problem is a bit bigger than threadsafety, you need to evoke transaction management.
The session generated by the session factory is threadlocal (spring's HibernateTransactionManager and the beanFactory that creates the sessuinFactory -for ex: AnnotationSessionFactoryBean- manages all this stuff)
So Your code is Safe ;)
I'm trying to wire up Spring Data JPA objects manually so that I can generate DAO proxies (aka Repositories) - without using a Spring bean container.
Inevitably, I will be asked why I want to do this: it is because our project is already using Google Guice (and on the UI using Gin with GWT), and we don't want to maintain another IoC container configuration, or pull in all the resulting dependencies. I know we might be able to use Guice's SpringIntegration, but this would be a last resort.
It seems that everything is available to wire the objects up manually, but since it's not well documented, I'm having a difficult time.
According to the Spring Data user's guide, using repository factories standalone is possible. Unfortunately, the example shows RepositoryFactorySupport which is an abstract class. After some searching I managed to find JpaRepositoryFactory
JpaRepositoryFactory actually works fairly well, except it does not automatically create transactions. Transactions must be managed manually, or nothing will get persisted to the database:
entityManager.getTransaction().begin();
repositoryInstance.save(someJpaObject);
entityManager.getTransaction().commit();
The problem turned out to be that #Transactional annotations are not used automatically, and need the help of a TransactionInterceptor
Thankfully, the JpaRepositoryFactory can take a callback to add more AOP advice to the generated Repository proxy before returning:
final JpaTransactionManager xactManager = new JpaTransactionManager(emf);
final JpaRepositoryFactory factory = new JpaRepositoryFactory(emf.createEntityManager());
factory.addRepositoryProxyPostProcessor(new RepositoryProxyPostProcessor() {
#Override
public void postProcess(ProxyFactory factory) {
factory.addAdvice(new TransactionInterceptor(xactManager, new AnnotationTransactionAttributeSource()));
}
});
This is where things are not working out so well. Stepping through the debugger in the code, the TransactionInterceptor is indeed creating a transaction - but on the wrong EntityManager. Spring manages the active EntityManager by looking at the currently executing thread. The TransactionInterceptor does this and sees there is no active EntityManager bound to the thread, and decides to create a new one.
However, this new EntityManager is not the same instance that was created and passed into the JpaRepositoryFactory constructor, which requires an EntityManager. The question is, how do I make the TransactionInterceptor and the JpaRepositoryFactory use the same EntityManager?
Update:
While writing this up, I found out how to solve the problem but it still may not be the ideal solution. I will post this solution as a separate answer. I would be happy to hear any suggestions on a better way to use Spring Data JPA standalone than how I've solve it.
The general principle behind the design of JpaRepositoryFactory and the according Spring integration JpaRepositoryFactory bean is the following:
We're assuming you run your application inside a managed JPA runtime environment, not caring about which one.
That's the reason we rely on injected EntityManager rather than an EntityManagerFactory. By definition the EntityManager is not thread safe. So if dealt with an EntityManagerFactory directly we would have to rewrite all the resource managing code a managed runtime environment (just like Spring or EJB) would provide you.
To integrate with the Spring transaction management we use Spring's SharedEntityManagerCreator that actually does the transaction resource binding magic you've implemented manually. So you probably want to use that one to create EntityManager instances from your EntityManagerFactory. If you want to activate the transactionality at the repository beans directly (so that a call to e.g. repo.save(…) creates a transaction if none is already active) have a look at the TransactionalRepositoryProxyPostProcessor implementation in Spring Data Commons. It actually activates transactions when Spring Data repositories are used directly (e.g. for repo.save(…)) and slightly customizes the transaction configuration lookup to prefer interfaces over implementation classes to allow repository interfaces to override transaction configuration defined in SimpleJpaRepository.
I solved this by manually binding the EntityManager and EntityManagerFactory to the executing thread, before creating repositories with the JpaRepositoryFactory. This is accomplished using the TransactionSynchronizationManager.bindResource method:
emf = Persistence.createEntityManagerFactory("com.foo.model", properties);
em = emf.createEntityManager();
// Create your transaction manager and RespositoryFactory
final JpaTransactionManager xactManager = new JpaTransactionManager(emf);
final JpaRepositoryFactory factory = new JpaRepositoryFactory(em);
// Make sure calls to the repository instance are intercepted for annotated transactions
factory.addRepositoryProxyPostProcessor(new RepositoryProxyPostProcessor() {
#Override
public void postProcess(ProxyFactory factory) {
factory.addAdvice(new TransactionInterceptor(xactManager, new MatchAlwaysTransactionAttributeSource()));
}
});
// Create your repository proxy instance
FooRepository repository = factory.getRepository(FooRepository.class);
// Bind the same EntityManger used to create the Repository to the thread
TransactionSynchronizationManager.bindResource(emf, new EntityManagerHolder(em));
try{
repository.save(someInstance); // Done in a transaction using 1 EntityManger
} finally {
// Make sure to unbind when done with the repository instance
TransactionSynchronizationManager.unbindResource(getEntityManagerFactory());
}
There must be be a better way though. It seems strange that the RepositoryFactory was designed to use EnitiyManager instead of an EntityManagerFactory. I would expect, that it would first look to see if an EntityManger is bound to the thread and then either create a new one and bind it, or use an existing one.
Basically, I would want to inject the repository proxies, and expect on every call they internally create a new EntityManager, so that calls are thread safe.
I'm trying to use a Spring JdbcTemplate instance to generate a DataSet useable for subsequent DBUnit tests.
any ideas how to do that?
all the documentation I found where going from a JDBC Connection instance to a IDatabaseConnection instance.
But the code I have abstract all this away using Spring, and what I have is a JdbcTemplate instance.
Any ideas?
Your jdbcTemplate bean has a dataSource property, so you can either get it from the jdbcTemplate with its getter or inject the dataSource (which you already have defined somewhere in your applicationContext) in your class where you build the IDatabaseConnection and use it as a constructor-arg for that. (you should do the latter)
See the following blog for a detailed explanation and full example (written by a springsource trainer)
http://blog.zenika.com/index.php?post/2010/02/04/Testing-SQL-queries-with-Spring-and-DbUnit%2C-part-1
http://blog.zenika.com/index.php?post/2010/02/05/Testing-SQL-queries-with-Spring-and-DbUnit%2C-part-2