find where the @inject Annotation is implemented, and see if there is a hook you can use. (From personal experience I can say that new annotations are not too difficult to write, i.e. a new @injectperrequest annotation might be a possibility).
find out how jpa generally would handle a session per request logic.
Hi, how about putting your application into a Java EE container (Widlfly, TomEE…) and putting all JPA tasks into an EJB? EJB is really easy to do and will make transaction boundaries automatically around your business methods.
Hi Matti, thank you for your answer. Unfortunately I’m not sure what you mean. I think with your approach I wouldn’t have session per request or I’m wrong? Which benefit would I have to put all my JPA interface methods inside of a EJB? This would be a big overhead.
It is still pretty much the session-per-request pattern, but just tackled by the Java EE server. Modern local EJBs are lightweight and as the EJB container automatically pools your EJBs, this approach is probably more efficient than something that you can achieve with your own custom JPA usage solution. Using local EJB’s will most likely make your application easier to write and perform better.
If I understand you correctly this means I would use EJB instead of JPA Repositories? How would such an EJB typically look like? Do I have to open hibernate sessions there or is it done by the container automatically? How does a db query look like inside of the EJB? With JPA Repositories I can simply use something like:
User user = userRepository.findByFirstnameAndLastName(firstname, lastname);
Sorry for asking this, but EJB is pretty new for me.
cheers
chris
You’ll still use JPA, but just access it through an EJB. As EJB is managed by the Java EE container, it can do all sorts of things that will make your app code simpler and still keep performing even better than by using JPA directly.