Re: [weld-dev] persistence and transactions outside Java EE

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(a)lycos.com&gt; *To:* Weld-Dev <weld-dev(a)lists.jboss.org&gt; *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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/weld-dev