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 <dan.j.allen(a)gmail.com> wrote:
On Fri, Mar 11, 2011 at 20:15, George Gastaldi
<gegastaldi(a)gmail.com>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