Vaadin & JEE6: EJB-Container does not create JEE-transaction for reques

Hello,

I’m using Vaadin with JEE6. My application is a stateful session bean (http://vaadin.com/wiki/-/wiki/Main/Creating%20JEE6%20Vaadin%20Applications). Persistence is realized with JPA (Hibernate as provider) and JTA for the transactions. PersistenceContext is Transaction and the TransactionManagement is done by the container.

I need to understand the following behaviour:

When the application’s init()-method is entered the SessionContext does have a transaction and loading my data, including lazy loading of some child entities, is working fine.

Now, there is a “refresh”-Button that shall reload all data when clicked.
BUT: When the ClickListener is entered, the SessionContext does NOT have a transaction. Therefore, every call to the bean that holds the EntityManager creates a new transaction and commits when done.
As a result my view components can’t display the entities lazy loaded children (org.hibernate.LazyInitializationException: could not initialize proxy - no Session)

I’m not sure why the container behaves like this. Maybe it has something to do with the transaction handling done by vaadin? Any ideads are welcome! It would by great if someone could give me some advice towards this problem.

Regards, Martin

I’ve found out the reason for the described behaviour:
The applications init method is called via the bean and so it automatically has a transaction.
The ClickListener’s method is called from the Servlet and therefore does NOT have a transaction.

A (probably) good way to work arround this is to add an implementation of the TransactionListener to the WebApplicationContext that opens a UserTransaction for every request.
Another solution is to wrap to whole vaadin stuff in another servlet and bean and let the container do the transaction management.

PS: I think it’s better not to deploy the vaadin application as an EJB (http://vaadin.com/wiki/-/wiki/Main/Creating%20JEE6%20Vaadin%20Applications). It unnecessarily complicates things and there is no advantage, since other EJBs can easily be accessed via the InitialContext (instead of using annotations)

I agree with you. I don’t think there’s much reason to use stateful EJBs at all with Vaadin since the state is already maintained in the HTTP session, let alone make a Vaadin app into a bean. But there are many ways to do this.

The way I (currently) like to do this is to extend AbstractApplicationServlet, inject whatever resources I want there, and pass them to the constructor of my Vaadin Application object. For instance, see the bottom of this class:


http://blogs.sun.com/bobby/resource/ee6_login/AuthApplication.java

(From
a blog
about using the login method on HttpServletRequest in Java EE 6.)

Cheers,
Bobby

Hello Bobby,

How do you handle that situation if you need say a lots of different beans in an large application?

I looking desperately for a way to provide those beans to different parts of my vaadin application without the need to pass them and the application class through all components. :confused:

Best Regards
MG

Hi Mathias,

Sorry for the delay, but I’m behind on the forums. I know it doesn’t sound helpful, but my first advice is “use fewer beans.” :slight_smile: At least you can use fewer at the UI level, and I’ll give you my thinking about this.

I tend to organize my applications so that the pieces are divided into an entity layer (e.g. JPA entities or whatever data model you’re using), service layer (the EJBs that perform the real logic), and the presentation layer (Vaadin in web layer, or an app client). Between the presentation and “back end” (services/entities), I have a boundary layer that the UI interacts with to actually do things. In a simple app, the boundary and service layers are the same.

Anyway, this boundary layer provides one interface for separating the client and back-end pieces. I declare my security there and can wrap any compound operations into single methods so that they’re wrapped in transactions and the UI layer never needs to worry about things like transactions. So, while this doesn’t really answer your question, it is an option for you to add this extra layer to simplify your Vaadin app. In practice, this is just another EJB or two (or three) that wraps related other EJBs. Then you have fewer beans in your Vaadin code.

Back to your main point, though: when I break up my Vaadin application into the Application class and supporting pieces, my Application class passes ‘this’ into the constructor of the other pieces, so they always have some way to call a getter on the app class to get a service bean (or just access it directly if it’s not private). I know some people use an accessible ThreadLocal object to store info like this, but I try to stay away from those. I like everything to be self-consistent when serialized to the HttpSession, but it’s just a personal preference.

I suppose you could have some component implement HttpServletRequestListener and get your Application class out of the session in onRequestStart(), but that seems like a lot of work.

There’s always the option of using JNDI in some component to look up the EJB you’re interested rather than passing the references around. I hope you find something that works well for you.

Cheers,
Bobby