Is it time for another major release of Narayana?

125 views
Skip to first unread message

Michael Musgrove

unread,
Sep 30, 2021, 10:38:42 AM9/30/21
to narayana-users
We have been on version 5.x for some years now and changes are afoot; items that spring to my mind include:

1. Support for JTA 2.0, EE 10 and jakarta namespace (this work is already well under way);
2. Java SE 17 and (possibly) dropping support for SE 8 (i.e. SE 11 will the minimum supported version);
3. Improved support for asynchronous APIs (although we continue to be tied to XA and very few resource managers support the asynchronous component of the XA spec [1], there are still things we would like to do in this area);
4. Drop Transactional Driver [2] in favour of Agroal [3];
5. An improved cloud strategy around recovery (again we have already started work in this area).

    section 3.5 Synchronous, Non-blocking and Asynchronous Modes

Ondra Chaloupka

unread,
Oct 4, 2021, 6:53:12 AM10/4/21
to narayana-users
The `txframework` (https://github.com/jbosstm/narayana/tree/5.12.1.Final/txframework) could be considered for removal. It's deprecated for some time and was replaced (or meant to be replaced) by `compensations` module (https://github.com/jbosstm/narayana/tree/5.12.1.Final/compensations).

Michael Musgrove

unread,
Nov 11, 2021, 4:44:01 AM11/11/21
to narayana-users
We are currently supporting EE9 via byte code transformation.

But at some point (Jakarta EE10!) we will need use source level transformation and use Jakarta Transactions 2.0 APIs directly in our source code.

We could do this in Narayana 6 but it does have impact on back porting fixes; although most of our code does not directly import javax.transaction so it will be a simple replacement of that with jakarta.transaction.xxx. And when new features are added to the spec then we would definitely need to move to source level changes.

I'd like to get some input from the community on whether it is ready for such a change?

Manuel Finelli

unread,
Nov 11, 2021, 6:23:47 AM11/11/21
to narayana-users
> Drop Transactional Driver [2] in favour of Agroal [3];

This sounds good :-) I already had a look at this and it seems feasible.

Talking about updating Arjuna, what if we try to replace FileLock with a native implementation? it would also be great if we could update to JUnit 5.

Mark Little

unread,
Nov 11, 2021, 6:34:41 AM11/11/21
to Manuel Finelli, narayana-users
If we can guarantee there's always a native implementation of FileLock available on all architectures, then go for it. Otherwise I'd prefer we provide alternatives, which can be selected at runtime or build time (e.g., Quarkus).

Mark.

--
You received this message because you are subscribed to the Google Groups "narayana-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to narayana-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/3cb31cc1-25c8-4542-baf5-345aff640844n%40googlegroups.com.

Manuel Finelli

unread,
Nov 11, 2021, 7:31:02 AM11/11/21
to narayana-users
> If we can guarantee there's always a native implementation of FileLock available on all architectures, then go for it

I will keep this in mind when trying to figure out JBTM-1761

> Otherwise I'd prefer we provide alternatives, which can be selected at runtime or build time (e.g., Quarkus).

The idea to provide alternatives sounds always good though

Manuel Finelli

unread,
Nov 11, 2021, 7:34:38 AM11/11/21
to narayana-users
In case the community supports the enhancement discussed in the thread "Call for contributions: how to store and generate the Node Identifier", I propose to introduce the automatic generation of node identifiers in our next major release.

Mark Little

unread,
Nov 11, 2021, 7:36:29 AM11/11/21
to Manuel Finelli, narayana-users
OK but that then brings us back to which implementation? Did you look at the licences of existing upstream efforts, as I suggested? I'd still prefer if we could collaborate upstream on something which already exists than craft something from scratch.

Mark.

--
You received this message because you are subscribed to the Google Groups "narayana-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to narayana-user...@googlegroups.com.

Manuel Finelli

unread,
Nov 11, 2021, 7:59:06 AM11/11/21
to narayana-users
I had a look at the licences of the upstream projects that I have indicated here. As far as I can tell, MIT is compatible with our licence so we should be able to use all of them.

Mark Little

unread,
Nov 11, 2021, 8:04:28 AM11/11/21
to Manuel Finelli, narayana-users
IANAL and as far as I'm aware neither are you. Worth checking with the Red Hat legal team on these things.

Mark.

Manuel Finelli

unread,
Nov 11, 2021, 9:03:58 AM11/11/21
to narayana-users
> Worth checking with the Red Hat legal team on these things.

+1

Mark Little

unread,
Nov 12, 2021, 3:23:00 AM11/12/21
to narayana-users, Manuel Finelli
Yes I think it's compatible too but it is better to check beforehand.

Manuel Finelli

unread,
Feb 2, 2022, 9:40:49 AM2/2/22
to narayana-users
It would be nice to drop JacORB from Narayana in our next major release (this is tracked with this JIRA). JacORB is not more an active project (last tag was released in 2017).

On Thursday, September 30, 2021 at 3:38:42 PM UTC+1 Michael Musgrove wrote:

Michael Musgrove

unread,
Nov 14, 2023, 7:16:12 AM11/14/23
to narayana-users
We have released a few versions since this question was raised so I am closing as complete.

Reply all
Reply to author
Forward
0 new messages