1

I have a complex process that is designed to be transactional, and is coded to be tranactional with Spring annotations. When I run it against databases that have XA aware drivers, it works well (apart from the headache of setting up each RDBMS to support XA).

However, I am trying to hook it up to HAWQ. HAWQ is XA aware to the point that it says, essentially, "Whoa Nellie, I don't do XA yet." Since I am likely to run into other backing stores that have similar limitations, the exact exception is not important, only the concept that I need to support non-XA datastores in what is normally an XA context, within certain very coarse limits.

The process is structured so that XA is a valuable luxury, but transactional failures that are not captured in the XA scope are non-critical.

For the class that talks to HAWQ (or classes that touch other future non-XA systems), is there a way to annotate the method to say "I know the caller is transactional, but I am not."?

I have already reviewed How to exclude a method to be @Transactional?, but it is solving a different problem.

class CallingClass
{
    @Transactional
    callingMethod ()
    {
        doSomeSetup ();
        methodFromWorkerClass();
    }
}

class NormalWorkerClass() implements Worker
{
    methodFromWorkerClass ()
    {
        doSomeStuff();
    }
}


class NonXAClass() implements Worker
{
    @INeedToBeNonXA
    methodFromWorkerClass ()
    {
        doSomeStuff();
    }
}
Community
  • 1
  • 1
pojo-guy
  • 966
  • 1
  • 12
  • 39
  • 1
    maybe Propagation.NOT_SUPPORTED would help? http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/transaction/annotation/Propagation.html – HRgiger Sep 20 '16 at 15:34
  • Most XA providers allow you to have 1 non-XA resource in a JTA transaction. If you only expect a single one, configure your JTA provider accordingly. If you expect multiple of those resources for your application, you might want to reconsider JTA/XA altogether. – M. Deinum Sep 20 '16 at 16:06
  • @HRgiger Per javadoc, Propagation.NOT_SUPPORTED is supposed to suspend transactions so they can be resumed elsewhere, but suspend/resume is not a guaranteed feature of XA providers. I thought this was my answer until the javadoc was read to me. – pojo-guy Sep 21 '16 at 07:11
  • @M. Deinum The resources are configured dynamically at runtime. Whether it's zero, one or many is a function of the target repositories. However, this points me in the direction of Quartz as a prototype, which requires both an XA and a non-XA datasource to function in the XA environment. My solution may be as simple as having the classes that talk to repositories that choke on XA instantiate their own non-XA connections (which I already have code for). – pojo-guy Sep 21 '16 at 07:14

0 Answers0