<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;<br><br>Actually one-phase commit optimization is required for the Transaction Managers. <br><br>See JCA 1.6 --> Section 7.6.3.3<br><br>--Gurkan<br></div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><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 8:47:32 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [weld-dev] persistence and transactions outside Java EE<br></font><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>>> src: <a href="http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/ms172070%28VS.80%29.aspx</a><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 ASP.NET <br>>> <<a href="http://ASP.NET"
target="_blank">http://ASP.NET</a>>!)<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>>> 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 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 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 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>>>> 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>>> > <a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>>> > <a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>>> > <a href="http://seamframework.org" target="_blank">http://seamframework.org</a><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>>> > --<br>>> > Dan Allen<br>>> > Senior Software Engineer, Red Hat | Author of Seam in Action<br>>> > Registered Linux User #231597<br>>> ><br>>> > <a
href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br>>> > <a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br>>> > <a href="http://www.google.com/profiles/dan.j.allen" target="_blank">http://www.google.com/profiles/dan.j.allen</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> <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><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><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>