[weld-dev] persistence and transactions outside Java EE

[Arbi Sookazian]

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!)

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> 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>> 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>
> >     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>
> >     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
> > 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/ddce5f89/attachment.html