Zee Zain wrote on Nov 04, 2011 11:24:
In latest reference guide for Seam Faces it says this part is not fleshed out. When is it going to be? When will the doc be updated?
I'll have to take a look at this part, and also get Brian to take a look and see what we were thinking here, thanks for pointing this one out.
I use latest Seam Beta4 with AS 7.0.1. I have UI workflows that are heavy on conversations/db access and I need to know how to configure my beans' transaction. Since Seam faces creates a transaction automatically do I still need to annotate my methods that deal with DB @Transactional?
No, you shouldn't have to.
I'm confused about transactions handling in Seam3. Can you please clarify the below:
1- When a JSF page calls a method on a CDI bean (request or session scoped), Seam faces automatically puts the whole request inside of a transaction? If yes, how do we handle what to do when the transaction is rolled back?
2- When a JSF page calls a an EJB (stateless or statefull), How does seam faces transaction handling change since EJBs are transaction by default? What about transaction rollback logic?
3- I have some seed data to import to DB when the app is deployed. Seam examples do this differently and I cannot find the proper way to do it. One option is to use Solder and observe app started event, this is a pain because transactions have to be managed manually using UserTransaction. Another option is using a servlet listener. But the beans have to be EJBs otherwise manual transaction management is needed. Is there any other options? Which one is better and why?
Yes, Seam Faces puts each request into it's own transaction. Rollback happens via the phaselistener in Seam faces. An event on transaction rollback (if there isn't already one) may be needed.
If it's an EJB call, the server should detect that there's already a transaction in place and not do anything. Of course if you're doing something like REQUIRES_NEW then things might get a little tricky.
Seeding is a little tough. EJBs work,an application listener (via CDI) with a transaction interceptor would work. If you're on Hibernate you can use import.sql, or whatever else is supported by your JPA implementation.