[weld-dev] persistence and transactions outside Java EE

Gurkan Erdogdu gurkanerdogdu at yahoo.com
Tue Nov 24 15:01:49 EST 2009


Hi Reza;

TM just executes second phase of the distributed transaction algorithm, i.e it does not run "prepare phase", directly executes commit phase with ONE_PHASE parameter true.


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. 

Thanks;

--Gurkan



________________________________
From: Reza Rahman <reza_rahman at lycos.com>
To: Weld-Dev <weld-dev at 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 at lycos.com>
> *To:* Weld-Dev <weld-dev at 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 at lycos.com 
> <mailto:reza_rahman at lycos.com>
> >> <mailto:reza_rahman at lycos.com <mailto:reza_rahman at 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 at gmail.com <mailto:gavin.king at gmail.com> 
> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>>
> >>    > <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com> 
> <mailto:gavin.king at gmail.com <mailto:gavin.king at 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 at gmail.com <mailto:gavin.king at gmail.com> 
> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>>
> >>    <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com> 
> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>>>
> >>    >    http://in.relation.to/Bloggers/Gavin
> >>    >    http://hibernate.org
> >>    >    http://seamframework.org
> >>    >    _______________________________________________
> >>    >    weld-dev mailing list
> >>    >    weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org> 
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>>
> >>    <mailto:weld-dev at lists.jboss.org 
> <mailto:weld-dev at lists.jboss.org> <mailto:weld-dev at lists.jboss.org 
> <mailto:weld-dev at 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 at lists.jboss.org <mailto:weld-dev at lists.jboss.org> 
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>>
> >>    > https://lists.jboss.org/mailman/listinfo/weld-dev
> >>
> >>    _______________________________________________
> >>    weld-dev mailing list
> >>    weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org> 
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>>
> >>    https://lists.jboss.org/mailman/listinfo/weld-dev
> >>
> >>
> >> _______________________________________________
> >> weld-dev mailing list
> >> weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org> 
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>>
> >> https://lists.jboss.org/mailman/listinfo/weld-dev
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/weld-dev
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

_______________________________________________
weld-dev mailing list
weld-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20091124/e687e739/attachment-0001.html 


More information about the weld-dev mailing list