I'm trying to get Audit records from hibernate using Interceptor class which extends EmptyInterceptor. My question is, does hibernate automatically configure and call methods in Interceptor class or do i have to make any configuration whatsoever in hibernate.cfg.xml or anywhere?
Yes. Exactly how you configure the Hibernate Interceptor depends on how you use Hibernate in your application - Via Spring JPA etc.
Related
Scenario:
I'm supporting an Enterprise application that runs in Wildfly10. The application (.war) uses J2EE technologies (EJBs, JPA, JAX-RS) and SpringBoot features (like, SpringMVC, SpringRest, SpringData, SpringRestData) ... Both stacks co-exists "happily" because they don't interact between them; however, they do share common classes, like utility or Entity Classes (the stacks map to the same database model). Why the application uses those stacks is out the scope of the question.
Currently, I'm trying to improve the performance of a #RestController that pulls some data from the database using a JPA Spring Repository. I found that we're suffering the N + 1 queries problem when calling the #RestController. In past projects (where there were only J2EE technologies), I have used the #BatchSize hibernate annotation to mitigate this problem with total success.
But, in this project, Spring seems to be skipping such annotation. How do I know that? Because I turned on the hibernate SQL logging (hibernate.show_sql) and I can see the N + 1 queries is still happening ...
Key Points:
Here are some insights about the application that you must know before providing (or trying to guess) any answer:
The application has many sub-modules encapsulated as libraries inside WAR file (/WEB-INF/lib) ... Some of these libraries are the jars that encapsulate the entity classes; others are the jars that encapsulate the REST Services (that could be JAX-RS services or Spring Controllers).
The Spring configuration is done in the classes defined in the WAR artifact: in there, we have a class (that extends from SpringBootServletInitializer) annotated with #SpringBootApplication and another class (that extends from RepositoryRestConfigurerAdapter) annotated with #Configuration. Spring customization is done is such class.
The application works with multiple datasources, which are defined in the Wildly server. Spring DATA JPA must address any query pointing to the right datasource. To accomplish this requirement, the application (Spring) was configured like this:
#Bean(destroyMethod="")
#ConfigurationProperties(prefix="app.datasource")
public DataSource dataSource() {
// the following class extends from AbstractRoutingDataSource
// and resolve datasources using JNDI names (the wildfly mode!)
return new DataSourceRouter();
}
#Bean("entityManagerFactory")
public LocalContainerEntityManagerFactoryBean getEntityManagerFactoryBean() {
LocalContainerEntityManagerFactoryBean lemfb;
lemfb = new LocalContainerEntityManagerFactoryBean();
lemfb.setPersistenceUnitName("abcd-pu");
lemfb.setDataSource(dataSource());
return lemfb;
}
The last #Bean declaration favors the use of a persistence.xml file, which we do have in the route /WEB-INF/classes/META-INF/ (i.e. Spring does find this file!) ... In such file, we define our domain classes, so that Spring JPA can see such entities. Also, we can define special JPA properties like: hibernate.show_sql and hibernate.use_sql_comments without issues (this is how I detected the N + 1 queries problem in the first place) ...
What I have done so far?
I tried to add the #BatchSize annotation to the problematic collection. No luck!
I created a new JAX-RS Service whose purpose was to mimic the behavior of the #RestController. I confirmed that the #BatchSize annotation does work in the application's deployment, at least, in JAX-RS Services! (NOTE: the service uses it own persistence.xml) ...
Test details (Updated 2020/07/30): What I did here was to create a new JAX-RS Service and deployed it inside the WAR application, next to the #RestController that presents the problem (I mean, it is the same WAR and the same physical JVM). Both services pull from database the same entity (same class - same classloader), which has a lazy Collection annotated with #BatchSize! ... If I invoke both services, the JAX-RS honors the #BatchSize and pulls the collection using the expected strategy, the #RestController does not ... So, what it is happening here? The only thing different between the services is that each one has a different persistence.xml: the persistence.xml for the JAX-RS is picked by Wildfly directly, the other one is picked by Spring and delegated to Wildfly (I guess) ...
I tried to add the properties: hibernate.batch_fetch_style (=dynamic) and hibernate.default_batch_fetch_size (=10), to the persistence.xml read by Spring ... No luck. I debug the Spring startup process and I saw that such properties are passed to the Spring Engine, but Spring does not care about them. The weird thing here is that properties like: hibernate.show_sql, Spring does honor them ... For those who are asking: "What does these properties do?" Well, they are global equivalent to apply #BatchSize to any JPA lazy collection or proxy without declaring such annotation in any entity.
I setup a small SpringBoot Project using the same Spring version as enterprise application (which is 1.5.8.RELEASE, by the way) and both the annotation and properties approach worked as supposed to.
I've been stuck with this issue for two days, any help to fix this will be appreciated ... thanks!
There are 2-3 possible issues that I can think off.
For some reason, whatever you modify isnt picked up by wildfly - Wildfly classpath resolution is a separate Topic and some missing configuration can cause you a nightmare. This you can identify if you have access to debug the query, and in if you put a breakpoint in the constructor of your Entity class, you will get a chance to evaluate the entity configuration being used, somewhere in the execution conetxt.
BatchSize doesnt work on OneToOne, It only works on OneToMany relationships.
A typical way to define BatchSize is to do along with Lazy load as mentioned in the example here. If you are not using Lazy fetch, hibernate assumes that you are willing to make an eager load and makes another select query to fetch all the details.Please confirm you are using the same syntax as given in the example above.
New Addition:
Put Conditional Breakpoints in PropertyBinder#setLazy() function, and may be backtrace it and put relavent breakpoints in CollectionBinder and AnnotationBinder. then restart/redeploy the server and see what data you are getting for the relavent properties. That will give you fair idea where it is failing..
Why conditional breakpoint? Its because you will have thousands of properties and if you do not add condition to the breakpoint, you will take 1 hour to reach your actual breakpoint
What should be the condition - If its property binder, the condition shoud be like `this.name == . For other classes also you can use the same approach.
Sorry for too detailed description on conditional breakpoints, you might find it redundent.
Looks like the only way to debug your problem is to debug hibernate framework from server startup, then only we will be able to find out the rootcause
I am using Mybatis 3.3.0 and EJB 3.1 running in a Wildfly 8.2.1 App server.
I modified my EJB's to have a Remote Interface and Injected the interface into all my classes that require the functionality instead of the injecting the LocalBean implementation (as it was before).
This caused all my useGeneratedKeys configurations for my mapper file Insert statements to stop working. Now my ID fields remain Null after the Inserts have run successfullly.
How is it that this caused mybatis to not be able to populate the ID's into my POJOs.
It turns out that mybatis gets confused when your EJB's are proxied and it isn't able to put the generated ID back into the POJO.
To fix it you simply have to inject the EJB Annotated with #javax.ejb.LocalBeanimplementation directly into the class you want to use it in. This is instead of injecting the Interface annotated with #javax.ejb.Remote.
Additionally I tested the same implementation using Remote EJB's and found you still won't be able to get generated Keys back from mybatis if you inject the #javax.ejb.Remote Interface type. I haven't found a solution to getting the generated ID into the POJO when using remoting.
I have a simple Spring Boot project (already mentioned here: Replace hsqldb with MySQL)
I would like to configure Hibernate to work with this project. In another project I used to get EntityManager like so:
#PersistenceContext(unitName = "orm-unit")
private EntityManager em;
but there I also have persistence.xml with required configuration.
In Spring Boot I don't even know where to place any configuration files.
How to make Hibernate work in this case?
Read the Spring Boot documentation. Looking over 31. Working with SQL databases you will see that you need to configure a DataSource.
DataSource configuration is controlled by external configuration
properties in spring.datasource.*. For example, you might declare the
following section in application.properties:
spring.datasource.url=jdbc:mysql://localhost/test
spring.datasource.username=dbuser
spring.datasource.password=dbpass
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
You can also configure a datasource in a #Configuration mapped class which implements EnvironmentAware.
JHipster generates a cool database configuration using HikariCP. You can check it out the sample here.
For Hibernate you can configure JPA properties.
You can set spring.jpa.hibernate.ddl-auto explicitly and the standard Hibernate property values are none, validate, update, create, create-drop. Spring Boot chooses a default value for you based on whether it thinks your database is embedded (default create-drop) or not (default none).
For example to create and drop tables you can add the following to your application.properties.
spring.jpa.hibernate.ddl-auto=create-drop
As for EntityManager when you EnableAutoConfiguration you will trigger a JpaBaseConfiguration which will create an entity manager for you.
You can also use a custom EntityManagerFactory.
To take full control of the configuration of the EntityManagerFactory,
you need to add a #Bean named ‘entityManagerFactory’. Spring Boot
auto-configuration switches off its entity manager based on the
presence of a bean of that type.
And btw you can also use a traditional persistence.xml
I have a EntityListener that needs to be configurable (typical data source info: driver, user, password), but I´d like to avoid adding one more properties file to the project. Is there any way to retrieve from some standard configuration place such as web.xml? It seems that injection via #Resource will be only available in JPA 2.1 (I am using JPA 2.0).
UPDATE - to make this clear
In my entity bean, I have an annotation #EntityListeners(MyEntityListener.class). So MyEntityListener may have methods annotated with #PostPersist for example. When my entity bean is gonna be persisted, this method is called. What I want is to retrieve the data for MyEntityListener initialization without using another configuration file.
http://openjpa.apache.org/builds/2.2.1/apidocs/org/apache/openjpa/audit/Auditor.html does the trick. It works (my bad, it was a misconfiguration of mine). Actually it works pretty well.
<property name="openjpa.Auditor" value="com.acme.Auditor(param2=10,param2='hello')"/>
IN spring docs it's written
The most important concepts to grasp with regard to the Spring Framework's declarative transaction
support are that this support is enabled via AOP proxies, and that the transactional advice is driven by
metadata (currently XML- or annotation-based).
So If i use
<tx:annotation-driven proxy-target-class="true" order="100"/>
in config file and not use #Transactional annotation on my beans. Would transaction still be supported, as I am using AOP and transaction Interceptor should be built-in to my AOPs thus no use of explicitly using #Transactional annotation.
Thanks,
No, you'd still have to use the #Transactional annotation. AOP proxy is only used to inject the transaction related code into your code.
< tx:annotation-driven /> is used to auto detect the '#Transactional' annotation .So it's necessary to have one . Reference here.
The proxy-target-class="true" decides whether Spring should use JDK dynamic proxies or CGLIB class based proxies . See the reference for more info . Basically if your class implements atleast one interface, JDK dynamic proxies are used . If you have a class MyDaoImpl extends MyDao and in your service , you inject the dao reference via MyDaoImpl myDaoImpl , JDK dynamic proxies will not work if the annotations are on your interface as class bases proxies are created with proxy-target-class="true" and #Transactional annotation is not inherited .
The reason why your queries seem to work without #Transactional may be because you are using hibernate template which opens and closes the transactions internally . From Spring 3 , it is recommended to inject sessionFactory directly and not to use hibernate template .
Hope this helps.