[weld-dev] persistence and transactions outside Java EE

Reza Rahman reza_rahman at lycos.com
Tue Nov 24 13:47:32 EST 2009 

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

More information about the weld-dev mailing list