Dan,

Generally speaking you are correct.  I agree that transaction APIs should be moved outside of persistence to allow other modules to use them without needing to use persistence.  I have already opened (and mostly coded) SEAMPERSIST-35 which separates the SeamManaged annotation from persistence.  The annotation was already moved to solder by Stuart in SOLDER-77.  I hope that SEAMPERSIST-35 can be integrated with Final so that the API calls are clear up front.  So I guess what else needs to come out and what does the timeframe look like for post Seam 3.0.0 for a supplemental release? I was targetting May for JCR.  To echo George's point, I've seen a few forum posts about JTA dependencies in Seam Persistence, when running it in a tomcat environment.  Is it possible for us to do this, while possibly degrading softly when it's not around?

John

On Fri, Mar 11, 2011 at 8:39 PM, Dan Allen <dan.j.allen@gmail.com> wrote:
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@gmail.com> wrote:
On Fri, Mar 11, 2011 at 20:15, George Gastaldi <gegastaldi@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





--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597



_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev