JCA? or a 'simple' XA adapter?

[guykatz]

hi all
I am trying to undestand what to do in my scenario:
using wildfly 23, i heavily use stateless EJB with bean managed transactions on top of a XA compliant datasource (a sybase database driver).
I am sloqly porting data from the RDBMS to microstream ( https://microstream.one/ ). And so, until the porting is comleted, I will have a product versions where half of the data will be in the RDMS and half in the microstream persistence engine.
Out of the box, microstrean cannot incorporate into the wildfly global transactions, it is not XA compliant (even though is has the notion of a transaction already in their API).
I am trying to figure out what is my best option to make it participate in the wildfly transactions.
I narrowed it down to writing a connector for microstream or just implementing an XA wrapper on top of it.
I am not sure which is best and what ironjacamar can "do" to help.
your comments are appreciated.

[fcorneli]

Out of the box, microstrean cannot incorporate into the wildfly global transactions, it is not XA compliant (even though is has the notion of a transaction already in their API).

But at least it's 400+ times faster. :)

[fcorneli]

I am slowly porting data from the RDBMS to microstream

Just out of curiosity, I always like to grasp the psychological behavior of developers, what made you think that this was a good idea in the first place?
Sure their web site states that it's much faster. But then again, imagine Alice and Malory go for a skydive. Alice jumps out of the plane and opens his parachute as parachutes have been around for ages and are known to work quite well. Malory wants to go faster and jumps without parachute. Passing Alice at high speed he can indeed scream "look I go faster". And the point is that at that very instance, Malory is completely right about it. He is going faster.

Most enterprise applications out there will inherently use different resources (databases, message queues, timers) which have to participate/coordinate in terms of transactions if you favor data consistency of your customer's data. As far as I know XA is thus far the only spec that indeed manages this in a vendor agnostic manner. Any "resource technology" that does not come with an XA compliant adapter should simply be avoided.

Those who claim that you can do without XA, most of the time end up reinventing two phase commit protocols themselves.

Doing a resource adapter yourself is possible,
https://github.com/e-Contract/ethereum-resource-adapter
but all but trivial.

And just in case you have the brilliant idea to start working on a resource adapter, ask yourself the following question: will you be able to maintain that incredible 400+ times faster claim?

I am trying to undestand what to do in my scenario

Create a git branch right before the point that you deviated from JPA and continue from there.
In the evening, take a bottle of whiskey, and have some self-reflection on how many months you lost and could have optimized your JPA queries instead.

[guykatz]

@fcorneli thanks for the comments.
I dont disagree with some of the things you say but disagree with others...
NOTE that speed increase is not the reason we port ( in many cases its not a big perf increase)... generally speaking, each enterprise application has its own limitations, restrictions, echo system, bahaviors etc,
for us, microstream fits like a glove - my only problem is the transition period where I am stuck with half a RDBMS and half microstream - and again, this is a limitation that I cant do anything about,,,
also, no one said I will wrap MS in XA or a resource adapter. I am just getting as much info as possible to make the right calls.

on a side note. an ultra normalized RDBMS with JPA on top is probably the worst way to go about for my application, and we have suffered greatly from that desicion but again, each app with its own criteria. I wouldnt discard MS as fast as you, its a very nice lib with many usecases that can fit many applications. you can also see the next gen frameworks supporting it and also pushing it (hellidon, micronaut etc)... but of course everyone should perform their own Due Diligence to see whats good in their specific situation... nothing is a silver bullet in life and in software