6:53 p.m.
John, George and Jordan,
I'm assuming that both the JMS and JCR modules will want to leverage the
transaction support for non-EJBs that is currently provided by Seam
Persistence, correct? Given that's the case, I proposed moving the
transaction APIs into the org.jboss.seam.transaction package. However, after
Seam 3.0 final, I'm thinking we should split this package into a transaction
module that can be shared. Does that sound like the right way to go?
https://issues.jboss.org/browse/SEAMPERSIST-34
Btw, you can use an @Unwraps method or proxy handler to enlist your resource
into the current transaction when the resource is dereferenced. See
https://github.com/seam/persistence/blob/master/impl/src/main/java/org/jb...
-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
7:15 p.m.
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 ?
Em 11/03/2011, às 21:54, Dan Allen <dan.j.allen(a)gmail.com> escreveu:
John, George and Jordan,
I'm assuming that both the JMS and JCR modules will want to leverage the
transaction support for non-EJBs that is currently provided by Seam
Persistence, correct? Given that's the case, I proposed moving the
transaction APIs into the org.jboss.seam.transaction package. However, after
Seam 3.0 final, I'm thinking we should split this package into a transaction
module that can be shared. Does that sound like the right way to go?
https://issues.jboss.org/browse/SEAMPERSIST-34
Btw, you can use an @Unwraps method or proxy handler to enlist your resource
into the current transaction when the resource is dereferenced. See
https://github.com/seam/persistence/blob/master/impl/src/main/java/org/jb...
-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
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
7:33 p.m.
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
7:39 p.m.
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
8 p.m.
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(a)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(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
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
6:07 p.m.
On Fri, Mar 11, 2011 at 21:00, John D. Ament <john.d.ament(a)gmail.com> wrote:
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?
Seam Persistence can operate in the absence of JTA. It then uses the
transaction provided by a resource, such as the EntityManager. This requires
explicit configuration, though, because the application developer has to
specify which resource to use as the transaction source. I suppose it could
be automatically selected. If you feel strongly about that, I welcome a
proposal ;)
-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
4994
days inactive
5005
days old
5 comments
3 participants
participants (3)
-
Dan Allen -
George Gastaldi -
John D. Ament