[hibernate-dev] Work on HHH-3110

[Les Hazlewood]

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