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?
On Fri, Mar 11, 2011 at 8:39 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
I'd also add that we are using transactions in the Faces module
managed transactions integrated into the JSF lifecycle. So again, we see the
transaction support used as a top-level feature.
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:
). 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 Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
seam-dev mailing list