Of course. There's no reason (other than FUD) to not use JTA even when
you have only a single resource.
Sent from my iPhone
On Nov 24, 2009, at 1:31 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
Transaction Managers do not engage in distributed transactions if
there is a single resource and that happens automatically.
JTA != 2PC.
Jonathan, correct me if I'm wrong, but I'm sure that's something you
guys have had in the product virtually for ever.
On 24 nov. 09, at 18:18, Arbi Sookazian wrote:
> This is a good idea from a corporate developer's perspective
> anyways. JEE platform needs to keep things as simple as possible
> (esp. in terms of configuration) for the typical JEE dev.
>
> "Promotable transactions optimize distributed transactions by
> deferring the creation of a distributed transaction until it is
> needed. If only one resource manager is required, no distributed
> transaction occurs."
>
> src:
http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx
>
> Instead of focusing on how "apparently" bad the Spring stack is, I
> would recommend focusing on expanding on the good ideas that .NET
> platform has (like the late addition of MVC frmwk in ASP.NET!)
>
> Corporate devs are looking to design and code use cases easily/
> quickly and not worry too much about system level issues,
> clustering and lack of tooling, etc. An integrated solution
> like .NET with the .NET Visual Studio IDE is very attractive
> (although somewhat limiting perhaps b/c the APIs/frmwks are
> "locked" down).
>
> We have to make way too many decisions about what frmwks and
> libraries to use in JEE (this problem seems to always be getting
> worse as the years go by unfortunately).
>
> On Tue, Nov 24, 2009 at 9:03 AM, Reza Rahman
> <reza_rahman(a)lycos.com> wrote:
> Dan,
>
> Personally, I think the most elegant solution in terms of Java EE is
> simply to standardize "promotable" transactions. Specifically, JTA
> could
> be modified to use local transactions by default and only promote
> transactions to distributed mode as the need arises. The Microsoft
> guys
> have had promotable transactions for ages, I am not sure why we don't
> have it in Java EE too. This would make the "lightweight" vs
> "heavyweight" debate moot and keep things simple/consistent from a
> developer's perspective while most of the systems-level issues are
> dealt
> by the container where these things belong instead of a steady leak
> as a
> development concern.
>
> Cheers,
> Reza
>
>
> Dan Allen wrote:
> > I was talking to someone about this topic post-Devoxx. I came up
> with
> > an idea that may be worth considering. Perhaps the Java EE platform
> > can recognize another class of bean that has persistence and
> > transaction capabilities, but not the rest of EJB. Here's my
> proposed
> > breakdown, in terms of airplane seat classes (I was on an
> airplane at
> > the time).
> >
> > First class - EJB session bean
> > Business class - local transactional bean
> > Coach - Simple managed bean
> >
> > The main differientiator of a "business class bean" from an EJB is
> > that it would have the option to use local transactions, just
> like an
> > application-managed JPA persistence unit. It would also not support
> > any HA concerns. But it would be a drop in replacement for so-
> called
> > "lightweight" transaction beans that Spring offers.
> >
> > Then, we wouldn't need to do anything special in Weld / Seam 3.
> All we
> > would need is to be able to support these types of beans in a
> servlet
> > container, the same way that Weld supports those environments.
> But it
> > would be a standard part of Java EE (6 MR1 or 7).
> >
> > If we feel like we need to support this use case in Seam, then
> clearly
> > there is still something missing in Java EE.
> >
> > -Dan
> >
> > On Wed, Nov 18, 2009 at 6:10 PM, Gavin King <gavin.king(a)gmail.com
> > <mailto:gavin.king@gmail.com>> wrote:
> >
> > I think we should try and follow the Java EE models as
> closely as
> > possible for this stuff. We should simply try and make the
> Java EE
> > code work outside EE 6.
> >
> > e.g.
> >
> > (1) use a resource declaration with @PersistenceContext
> (unitName=....)
> > to define a managed persistence context
> > (2) use JBoss Transactions to manage transactions in a
> servlet engine
> > - so instead of having a special tx manager for JDBC, it is
> just JTA
> >
> > Or is the 10meg download for JBoss Transactions just no good?
> >
> > --
> > Gavin King
> > gavin.king(a)gmail.com <mailto:gavin.king@gmail.com>
> >
http://in.relation.to/Bloggers/Gavin
> >
http://hibernate.org
> >
http://seamframework.org
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org>
> >
https://lists.jboss.org/mailman/listinfo/weld-dev
> >
> >
> >
> >
> > --
> > Dan Allen
> > Senior Software Engineer, Red Hat | Author of Seam in Action
> > Registered Linux User #231597
> >
> >
http://mojavelinux.com
> >
http://mojavelinux.com/seaminaction
> >
http://www.google.com/profiles/dan.j.allen
> >
> ---
> ---------------------------------------------------------------------
> >
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/weld-dev
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/weld-dev
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev