Nope - no coupling required :)
What I'm proposing is purely restricted to Hibernate's existing
dependencies and would work for any TM implementation, not just
Atomikos or JOTM.
It is the TM-specific TransactionManagerLookup (or perhaps a
TM-specific JTATransactionFactory) that would choose the
implementation to use at runtime.
On Thu, Jun 19, 2008 at 5:49 PM, Chris Bredesen <cbredesen(a)redhat.com> wrote:
Les Hazlewood wrote:
>
> I agree with you Chris, it does better simulate it. But Hibernate has
> always been deployable outside of a container. Shouldn't it retain
> that philosophy in its code base as well, architecting flexible
> approaches that work seamlessly both in a JEE container and out?
>
> That's my belief...
Sure, and that's exactly why all this stuff is pluggable. An alternative
would be for the TM projects to incorporate implementations of the Hibernate
classes that most efficiently use their own APIs. MySQL, for example,
provides a JBoss ValidConnectionChecker that is statically linked to their
own driver. Collaboration like this is great, IMHO.
Does your proposed implementation require Atomikos to be on the classpath in
order to build Hibernate? The use of JNDI decouples Hibernate from the TM
in a well-specified way.
-Chris