I'd also add that we are using transactions in the Faces module to provide managed transactions integrated into the JSF lifecycle. So again, we see the transaction support used as a top-level feature.
-Dan On Fri, Mar 11, 2011 at 20:33, Dan Allen <[email protected]> wrote: > On Fri, Mar 11, 2011 at 20:15, George Gastaldi <[email protected]>wrote: > >> Nice, I agree that it is the right way to go. I was almost suggesting >> separating that on a separate module also. >> >> However it must be considered that JTA would not always be used (when >> running on tomcat for example). How would this module handle these scenarios >> ? Would it depend on persistence module itself ? >> > > The Seam transaction API is an abstraction over JTA. It provides the same > interface, but can accommodate a different providers underneath. > > For instance, you should be able to adapt it to any single resource > transaction (recognizing that you lose multiple resource enlistment) > (similar to what spring does: > http://www.infoq.com/articles/spring-modules-jcr). The module could even > go a step further and provide simplified transaction configuration for JTA > in a standalone environment. I think there is a lot of interesting avenues > to explore, which is why having it in a separate module makes a ton of > sense. The floor is open for discussion. > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
