[weld-dev] persistence and transactions outside Java EE

Gavin King gavin.king at gmail.com
Tue Nov 24 15:14:19 EST 2009 

But that's where I think you're getting mixed up. JTA is not part of
EJB. @TransactionAttribute is part of EJB. And there's no reason you
can't use JTA for local transactions. So I don't understand what's
wrong with the idea of Tomcat+Weld+Hibernate+JBoss Transactions + some
kind of pooling. We don't need a new kind of bean or a new kind of
container transaction. All we need is for @TransactionAttribute or
equivalent to work for something that is not an EJB.

On Tue, Nov 24, 2009 at 3:05 PM, Dan Allen <dan.j.allen at gmail.com> 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> 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>
>> > *To:* Weld-Dev <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>!)
>> > >>
>> > >> 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>>> 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>>>> 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>>>
>> > >>    >    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>>>
>> > >>    >    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>>
>> > >>    > 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
>> >
>> > _______________________________________________
>> > 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
>> >
>>
>> _______________________________________________
>> weld-dev mailing list
>> 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
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org

More information about the weld-dev mailing list