[hibernate-dev] Work on HHH-3110

[Steve Ebersole]

Hey Les, yes it has been a long time.

Not sure why you find it so interesting considering that that JTA spec
itself *requires* binding into JNDI :)  This is true both in the older
1.0.1B as well as the latest 1.1 specs.  Thus I do not believe
that org.hibernate.transaction.JTATransaction is the correct place to
be adding support for not acquiring these resources from JNDI.  

However, I have no issue with adding support for these psuedo-JTA TMs.
Its just a matter of semantics and being consistent with terminology.
So, the basic thing we are trying to describe is support for interacting
with "distributed transaction" systems.  So, I'd prefer that the base
class in question here be called DistributedTransaction, of which
JTATransaction would be a subclass with the same behavior as it has
today (some delegated to its new super).  And from there we can begin to
build the support for Atomikos and the other TP services not conforming
to the JNDI aspect of the JTA spec.


On Thu, 2008-06-19 at 16:42 -0400, Les Hazlewood wrote:
> Hi guys,
> 
> It has been a while since I've talked to most of the Hibernate team -
> I hope all is well with everyone.  I can say that I miss that I miss
> working with the people, not so much the consulting travel :-P
> 
> Anyway, lemme get to business.
> 
> I upgraded from 3.2.5 to 3.2.6 and started getting exceptions about
> JNDI.  The company I'm working with uses Atomikos standalone
> transaction manager outside of a JEE environment (no JNDI necessary),
> I found this issue that exactly describes what I'm seeing:
> 
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3110
> 
> It was interesting to see from many posts on the web that many other
> people are seeing the same issue, BTM, Jotm, Atomikos users, etc...
> 
> So, I started thinking, and communicated with Chris since the issue
> was assigned to him.  Here's a summary:
> 
> Les:  I want to make some architectural adjustments to the
> org.hibernate.transaction.JTATransaction implementation that would
> work with or without JNDI, but be fully backwards compatible.
> 
> Any objections to me assigning the issue to myself?
> 
> Chris: I have an objection only insomuch as JTA implies JNDI
> availability. Open up this issue on hibernate-dev and let's flesh it
> out with Steve. I think the right solution is to provide an additional
> implementation that uses JOTM directly, as suggested by Felix on the
> JIRA case.
> 
> So, here I am.
> 
> The issue with JTATransaction is that it acquires the the
> UserTransaction object via a JNDI lookup.  If JNDI isn't being used,
> we have the exception.
> 
> The proposed solution is to create an AbstractJTATransaction that does
> exactly what the current implementation does, but abstracts the
> UserTransaction lookup to subclasses.
> 
> Then JTATransaction would subclass AbstractJTATransaction and
> implement the default JNDI lookup logic as exists today.
> 
> A new class, say a StandaloneJTATransaction would subclass
> AbstractJTATransaction and acquire it via a different mechanism -
> probably the TM-specific TransactionManagerLookup implementation looks
> it up first and then passes it in the StandaloneJTATransaction
> constructor.
> 
> Anyway, this would be fully backwards compatible because the
> JTATransaction implementation would retain the same API and
> functionality.  It would just support non-JNDI environments very
> cleanly and the TransactionManagerLookup implementation, which is
> already TM-specific, would know what to do based on if it requires
> JNDI or not.
> 
> So what do you think?  Can I make this change in my local environment
> and upload the patch to the issue to see how you guys like it?  It
> would make a lot of users (including me ;) ) quite happy, while still
> retaining the JNDI defaults as expected by JTA.
> 
> Cheers!
> 
> Les
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev