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

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>> 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>>> 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>> > > 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>> > > 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> > > 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 ------------------------------------------------------------------------ _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev