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
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.-DanOn 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 AllenPrincipal 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 AllenPrincipal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev