[weld-dev] persistence and transactions outside Java EE
Reza Rahman
reza_rahman at lycos.com
Tue Nov 24 15:33:29 EST 2009
Dan,
It's somewhat related....in terms of Resin, we actually don't have such
a thing as a traditional EJB container - we have "aspects" such as
transactions delivered via meta-data (e.g. @TransactionAttribute), the
aspects are bound to an underlying implementation (e.g. transaction
manager) and can be used in any component model including managed beans
or EJB. The "EJB Lite" distinction is tenuous since you don't really
need to use the EJB component model per se.
I think the JTA overhead issue is relevant only in that if there really
isn't significant performance implications, there isn't a reason to not
simply include a JTA capable transaction manager as part of an embedded
solution (perhaps as the default option). From the emails just posted,
it seems the issue of overhead is mostly moot since you would need a
transaction manager role regardless of JTA or local transactions.
Cheers,
Reza
Dan Allen wrote:
> We actually have parallel conversations going here. Putting aside the
> question of JTA overhead, the main concern is that JTA transactions
> simply aren't available in a servlet environment (without extra
> configuration). Hence my idea of having a lightweight transactional
> bean that makes use of local transactions rather than requiring JTA
> transactions provided by an EJB (or EJB lite) container.
>
> Or perhaps, it's all unnecessary and we just tell people to use EJB
> lite if they want transactions and persistence.
>
> -Dan
>
> On Tue, Nov 24, 2009 at 2:49 PM, Reza Rahman <reza_rahman at lycos.com
> <mailto:reza_rahman at lycos.com>> wrote:
>
> Gurkan,
>
> Thanks for that...reading through JTA/JCA has been on my wish-list
> for a
> while, I just haven't gotten around to it yet - the blog post
> exploring
> JTA performance would have been my final impetus :-).
>
> So the real overhead of JTA in optimized mode is what exactly (as
> far as
> you know)?
>
> Cheers,
> Reza
>
>
> Gurkan Erdogdu wrote:
> > 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 at lycos.com
> <mailto:reza_rahman at lycos.com>>
> > *To:* Weld-Dev <weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>
> > *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>
> > >> <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 at lycos.com <mailto:reza_rahman at lycos.com>
> > <mailto:reza_rahman at lycos.com <mailto:reza_rahman at lycos.com>>
> > >> <mailto:reza_rahman at lycos.com <mailto:reza_rahman at lycos.com>
> <mailto:reza_rahman at lycos.com <mailto: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>
> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>>
> > <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>
> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>>>
> > >> > <mailto:gavin.king at gmail.com
> <mailto:gavin.king at gmail.com> <mailto:gavin.king at gmail.com
> <mailto:gavin.king at gmail.com>>
> > <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>
> <mailto: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>
> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>>
> > <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>
> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>>>
> > >> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>
> <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>>
> > <mailto:gavin.king at gmail.com <mailto:gavin.king at gmail.com>
> <mailto: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> <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>
> > <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org> <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>>
> > >> <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>
> > <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
> > <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>>>
> > >> > https://lists.jboss.org/m ailman/listinfo/weld-dev
> <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
> <mailto:weld-dev at lists.jboss.org> <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>
> > <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org> <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>>
> > >> > https://lists.jboss.org/mailman/listinfo/weld-dev
> > >>
> > >> _______________________________________________
> > >> weld-dev mailing list
> > >> weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>>
> > <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org> <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>>
> > >> https://lists.jboss.org/mailman/listinfo/weld-dev
> > >>
> > >>
> > >> _______________________________________________
> > >> weld-dev mailing list
> > >> weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>>
> > <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org> <mailto:weld-dev at lists.jboss.org
> <mailto:weld-dev at lists.jboss.org>>>
> > >> https://lists.jboss.org/mailman/listinfo/weld-dev
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > weld-dev mailing list
> > > weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
> <mailto:weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
>
> _______________________________________________
> 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
More information about the weld-dev
mailing list