[weld-dev] persistence and transactions outside Java EE
Gurkan Erdogdu
gurkanerdogdu at yahoo.com
Tue Nov 24 14:03:50 EST 2009
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>> 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>>> 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>>
>> > 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>>
>> > 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>
>> > 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
_______________________________________________
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/305b25a3/attachment-0001.html
More information about the weld-dev
mailing list