I did try to implement the approach explained within this article getting the UserTransaction from jndi and worked perfectly, however I'm concerned about side effects I cannot imagine right now.
Any thoughts/experience you might share?
Help/feedback is highly appreciated!
If it works, it ain't broken ;-)
Of course if the load is high and page rendering (request) takes a long time, you will keep the transaction open for the whole time which (depending on your data access) might cause unneccessary locks (guessing here)
Well, my tests have been quite basic :-(. Let's see what happens when I scale them... Any other thoughts?
My preferred approach has been to use a two phase approach, without using the "open session in view" pattern.
- If the request is an update operation, then invoke an EJB3 with all the request parameters and perform the update in a single transaction demarcated on the EJB.
- If the update succeeds forward to a response renderer that prepopulates another stateless EJB3 with the values needed to render the result, using @Producer methods to provide the prepopulated named pojos that can be accessed from the JSP or facelet. The @Producer methods would be annotated with @TransactionAttribute(NOT_SUPPORTED)
If it's not an update operation, then only step 2 applies. In some circumstances it may be appropriate to use the same EJB for both steps.
For performance and scalability you want to minimise the number of transactions that begin and commit during the HTTP request/response cycle.