[hibernate-dev] Work on HHH-3110

Les Hazlewood les at hazlewood.com
Fri Jun 20 09:52:37 EDT 2008


Hi Steve!

Great to hear from you again :)

> 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.

My frustration lies in the JTA spec itself, requiring JNDI due to
remnants from the EJB 2.1 era.  Which is why I consider my approach to
be a feature request as opposed to a bug - its a 'nice to have' when
using a JTA TM that doesn't require JNDI.

And I agree that JTATransaction _should_ be using the JNDI lookup - my
intention was never to change that, ensuring 100% backwards
compatibility.  My intention was that the JTATransaction was a minimal
subclass of a parent abstract class.  That abstract class would
delegate to children classes how do do the lookup, and in the
JTATransaction case, it would do it from JNDI, just as things occur
today.

> 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.

Perfect, this is exactly my thinking as well.  And I much prefer your
superclass name ;)   I'll post to this list again when I have my patch
attached to the issue so you guys can see the end result.

Thanks again,

Les




More information about the hibernate-dev mailing list