<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div>Hi Reza;<br><br>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.<br></div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><br>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. <br><br>Thanks;<br><br>--Gurkan<br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Reza Rahman <reza_rahman@lycos.com><br><b><span style="font-weight: bold;">To:</span></b> Weld-Dev <weld-dev@lists.jboss.org><br><b><span style="font-weight: bold;">Sent:</span></b> Tue, November
24, 2009 9:49:41 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [weld-dev] persistence and transactions outside Java EE<br></font><br>
Gurkan,<br><br>Thanks for that...reading through JTA/JCA has been on my wish-list for a <br>while, I just haven't gotten around to it yet - the blog post exploring <br>JTA performance would have been my final impetus :-).<br><br>So the real overhead of JTA in optimized mode is what exactly (as far as <br>you know)?<br><br>Cheers,<br>Reza<br><br><br>Gurkan Erdogdu wrote:<br>> Hi;<br>><br>> Actually one-phase commit optimization is required for the Transaction <br>> Managers.<br>><br>> See JCA 1.6 --> Section 7.6.3.3<br>><br>> --Gurkan<br>><br>> ------------------------------------------------------------------------<br>> *From:* Reza Rahman <<a ymailto="mailto:reza_rahman@lycos.com" href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>><br>> *To:* Weld-Dev <<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>><br>> *Sent:* Tue,
November 24, 2009 8:47:32 PM<br>> *Subject:* Re: [weld-dev] persistence and transactions outside Java EE<br>><br>> Emmanuel,<br>><br>> From what I understand, this is an optimization that almost all sane<br>> JTA providers have but it is not standards defined behavior. Also, I<br>> think a sane JTA transaction manager could work with a non-XA resource<br>> in optimized/local mode (again something I think could be defined at the<br>> spec level but isn't).<br>><br>> I'm looking into some of these issues myself vis-a-vis Resin's<br>> transaction manager and am thinking this could be a valuable blog topic<br>> to help clear the air on some of this...<br>><br>> Cheers,<br>> Reza<br>><br>><br>> Emmanuel Bernard wrote:<br>> > Transaction Managers do not engage in distributed transactions if<br>> > there is a single resource and that happens automatically.<br>> > JTA != 2PC.<br>>
> Jonathan, correct me if I'm wrong, but I'm sure that's something you<br>> > guys have had in the product virtually for ever.<br>> ><br>> > On 24 nov. 09, at 18:18, Arbi Sookazian wrote:<br>> ><br>> >> This is a good idea from a corporate developer's perspective<br>> >> anyways. JEE platform needs to keep things as simple as possible<br>> >> (esp. in terms of configuration) for the typical JEE dev.<br>> >><br>> >> "Promotable transactions optimize distributed transactions by<br>> >> deferring the creation of a distributed transaction until it is<br>> >> needed. If only one resource manager is required, no distributed<br>> >> transaction occurs."<br>> >><br><span>> >> src: <a target="_blank"
href="http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx">http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx</a></span><br>> >><br>> >> Instead of focusing on how "apparently" bad the Spring stack is, I<br>> >> would recommend focusing on expanding on the good ideas that .NET<br>> >> platform has (like the late addition of MVC frmwk in <a target="_blank" href="http://ASP.NET">ASP.NET</a><br><span>> >> <<a target="_blank" href="http://ASP.NET">http://ASP.NET</a>>!)</span><br>> >><br>> >> Corporate devs are looking to design and code use cases<br>> >> easily/quickly and not worry too much about system level issues,<br>> >> clustering and lack of tooling, etc. An integrated solution like<br>> >> .NET with the .NET Visual Studio IDE is very attractive (although<br>> >> somewhat limiting perhaps b/c the APIs/frmwks are
"locked" down).<br>> >><br>> >> We have to make way too many decisions about what frmwks and<br>> >> libraries to use in JEE (this problem seems to always be getting<br>> >> worse as the years go by unfortunately).<br>> >><br>> >> On Tue, Nov 24, 2009 at 9:03 AM, Reza Rahman <<a ymailto="mailto:reza_rahman@lycos.com" href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a> <br>> <mailto:<a ymailto="mailto:reza_rahman@lycos.com" href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>><br>> >> <mailto:<a ymailto="mailto:reza_rahman@lycos.com" href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a> <mailto:<a ymailto="mailto:reza_rahman@lycos.com" href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>>>> wrote:<br>> >><br>> >> Dan,<br>> >><br>> >> Personally, I think the most elegant
solution in terms of Java EE is<br>> >> simply to standardize "promotable" transactions. Specifically,<br>> >> JTA could<br>> >> be modified to use local transactions by default and only promote<br>> >> transactions to distributed mode as the need arises. The<br>> >> Microsoft guys<br>> >> have had promotable transactions for ages, I am not sure why we <br>> don't<br>> >> have it in Java EE too. This would make the "lightweight" vs<br>> >> "heavyweight" debate moot and keep things simple/consistent from a<br>> >> developer's perspective while most of the systems-level issues<br>> >> are dealt<br>> >> by the container where these things belong instead of a steady<br>> >> leak as a<br>>
>> development concern.<br>> >><br>> >> Cheers,<br>> >> Reza<br>> >><br>> >><br>> >> Dan Allen wrote:<br>> >> > I was talking to someone about this topic post-Devoxx. I came<br>> >> up with<br>> >> > an idea that may be worth considering. Perhaps the Java EE <br>> platform<br>> >> > can recognize another class of bean that has persistence and<br>> >> > transaction capabilities, but not the rest of EJB. Here's my<br>> >> proposed<br>> >> > breakdown, in terms of airplane seat classes (I was on an<br>> >> airplane at<br>> >> > the time).<br>> >> ><br>> >> > First class - EJB
session bean<br>> >> > Business class - local transactional bean<br>> >> > Coach - Simple managed bean<br>> >> ><br>> >> > The main differientiator of a "business class bean" from an EJB is<br>> >> > that it would have the option to use local transactions, just<br>> >> like an<br>> >> > application-managed JPA persistence unit. It would also not <br>> support<br>> >> > any HA concerns. But it would be a drop in replacement for<br>> >> so-called<br>> >> > "lightweight" transaction beans that Spring offers.<br>> >> ><br>> >> > Then, we wouldn't need to do anything special in Weld / Seam 3.<br>> >> All we<br>> >> >
would need is to be able to support these types of beans in a<br>> >> servlet<br>> >> > container, the same way that Weld supports those environments.<br>> >> But it<br>> >> > would be a standard part of Java EE (6 MR1 or 7).<br>> >> ><br>> >> > If we feel like we need to support this use case in Seam, then<br>> >> clearly<br>> >> > there is still something missing in Java EE.<br>> >> ><br>> >> > -Dan<br>> >> ><br>> >> > On Wed, Nov 18, 2009 at 6:10 PM, Gavin King<br>> >> <<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a> <mailto:<a ymailto="mailto:gavin.king@gmail.com"
href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>> <br>> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>>><br>> >> > <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>> <br>> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>>>>> wrote:<br>> >> ><br>> >> > I think we should try and follow the Java EE models
as<br>> >> closely as<br>> >> > possible for this stuff. We should simply try and make the<br>> >> Java EE<br>> >> > code work outside EE 6.<br>> >> ><br>> >> > e.g.<br>> >> ><br>> >> > (1) use a resource declaration with<br>> >> @PersistenceContext(unitName=....)<br>> >> > to define a managed persistence context<br>> >> > (2) use JBoss Transactions to manage transactions in a<br>> >> servlet engine<br>> >> > - so instead of having a special tx manager for JDBC, it is<br>> >> just JTA<br>> >> ><br>>
>> > Or is the 10meg download for JBoss Transactions just no good?<br>> >> ><br>> >> > --<br>> >> > Gavin King<br>> >> > <a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>> <br>> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>>><br>> >> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a> <mailto:<a ymailto="mailto:gavin.king@gmail.com"
href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>> <br>> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a> <mailto:<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>>>><br><span>> >> > <a target="_blank" href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a></span><br><span>> >> > <a target="_blank" href="http://hibernate.org">http://hibernate.org</a></span><br><span>> >> > <a target="_blank" href="http://seamframework.org">http://seamframework.org</a></span><br>> >> > _______________________________________________<br>> >> > weld-dev mailing list<br>> >> > <a
ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>> <br>> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>>><br>> >> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <br>> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <br>> <mailto:<a
ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>>>><br>> >> > <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>> >> ><br>> >> ><br>> >> ><br>> >> ><br>> >> > --<br>> >> > Dan Allen<br>> >> > Senior Software Engineer, Red Hat | Author of Seam in Action<br>> >> > Registered Linux User #231597<br>> >> ><br><span>> >> > <a target="_blank" href="http://mojavelinux.com">http://mojavelinux.com</a></span><br><span>> >> > <a target="_blank"
href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a></span><br><span>> >> > <a target="_blank" href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a></span><br>> >> ><br>> >> <br>> ------------------------------------------------------------------------<br>> >> ><br>> >> > _______________________________________________<br>> >> > weld-dev mailing list<br>> >> > <a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>> <br>> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org"
href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>>><br>> >> > <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>> >><br>> >> _______________________________________________<br>> >> weld-dev mailing list<br>> >> <a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>> <br>> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a
ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>>><br>> >> <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>> >><br>> >><br>> >> _______________________________________________<br>> >> weld-dev mailing list<br>> >> <a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>> <br>> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>>><br>> >> <a
href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>> ><br>> > ------------------------------------------------------------------------<br>> ><br>> > _______________________________________________<br>> > weld-dev mailing list<br>> > <a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>><br>> > <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>><br>> _______________________________________________<br>> weld-dev mailing list<br>> <a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a> <mailto:<a
ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>><br>> <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>><br><br>_______________________________________________<br>weld-dev mailing list<br><a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br></div></div>
<!-- cg17.c1.mail.mud.yahoo.com compressed/chunked Tue Nov 17 21:32:47 PST 2009 -->
</div><br>
</body></html>