But it has still more overhead than a local-transaction mode. Because TM has always a role whether it is 2-PC or 1-PC.
From: Reza Rahman <reza_rahman@lycos.com>
To: Weld-Dev <weld-dev@lists.jboss.org>
Sent: Tue, November
24, 2009 9:49:41 PM
Subject: Re: [weld-dev] persistence and transactions outside Java EE
Gurkan,
Thanks for that...reading through JTA/JCA has been on my wish-list for a
while, I just haven't gotten around to it yet - the blog post exploring
JTA performance would have been my final impetus :-).
So the real overhead of JTA in optimized mode is what exactly (as far as
you know)?
Cheers,
Reza
Gurkan Erdogdu wrote:
> Hi;
>
> Actually one-phase commit optimization is required for the Transaction
> Managers.
>
> See JCA 1.6 --> Section 7.6.3.3
>
> --Gurkan
>
> ------------------------------------------------------------------------
> *From:* Reza Rahman <
reza_rahman@lycos.com>
> *To:* Weld-Dev <
weld-dev@lists.jboss.org>
> *Sent:* Tue,
November 24, 2009 8:47:32 PM
> *Subject:* Re: [weld-dev] persistence and transactions outside Java EE
>
> Emmanuel,
>
> From what I understand, this is an optimization that almost all sane
> JTA providers have but it is not standards defined behavior. Also, I
> think a sane JTA transaction manager could work with a non-XA resource
> in optimized/local mode (again something I think could be defined at the
> spec level but isn't).
>
> I'm looking into some of these issues myself vis-a-vis Resin's
> transaction manager and am thinking this could be a valuable blog topic
> to help clear the air on some of this...
>
> Cheers,
> Reza
>
>
> Emmanuel Bernard 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> >> <http://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@lycos.com > <mailto:
reza_rahman@lycos.com>
> >> <mailto:
reza_rahman@lycos.com <mailto:
reza_rahman@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@gmail.com <mailto:
gavin.king@gmail.com>
> <mailto:
gavin.king@gmail.com <mailto:
gavin.king@gmail.com>>
> >> > <mailto:
gavin.king@gmail.com <mailto:
gavin.king@gmail.com>
> <mailto:
gavin.king@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@gmail.com <mailto:
gavin.king@gmail.com>
> <mailto:
gavin.king@gmail.com <mailto:
gavin.king@gmail.com>>
> >> <mailto:
gavin.king@gmail.com <mailto:
gavin.king@gmail.com>
> <mailto:
gavin.king@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@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>
> <mailto:
weld-dev@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>>
> >> <mailto:
weld-dev@lists.jboss.org > <mailto:
weld-dev@lists.jboss.org> <mailto:
weld-dev@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@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>
> <mailto:
weld-dev@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>>
> >> >
https://lists.jboss.org/mailman/listinfo/weld-dev> >>
> >> _______________________________________________
> >> weld-dev mailing list
> >>
weld-dev@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>
> <mailto:
weld-dev@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>>
> >>
https://lists.jboss.org/mailman/listinfo/weld-dev> >>
> >>
> >> _______________________________________________
> >> weld-dev mailing list
> >>
weld-dev@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>
> <mailto:
weld-dev@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>>
> >>
https://lists.jboss.org/mailman/listinfo/weld-dev> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > weld-dev mailing list
> >
weld-dev@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>
> >
https://lists.jboss.org/mailman/listinfo/weld-dev>
> _______________________________________________
> weld-dev mailing list
>
weld-dev@lists.jboss.org <mailto:
weld-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/weld-dev>
_______________________________________________
weld-dev mailing list
weld-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/weld-dev