Narayana Community Priorities
The following is an outline of our near term priorities for the Narayana open source transaction manager. They have been set based on input from the community, including the narayana-users forum discussion.
It is not necessarily a complete list, so please continue to share your own thoughts on whether you agree they are the right focus for the project, in some respects the list is quite ambitious and we encourage/need and welcome continued contributions and discussion from the community to help achieve these goals.
Community Engagement
- Improve inclusiveness by building a community of users:
- produce clear guidance on how to contribute with different levels of guidance
- responsive to the community (PRs, queries, issues, rooms etc)
- issue labels for new contributors and for tasks that we need help with
- make sure all new features are publicised (blog, articles, docs, etc)
- regular blog posts with runnable and focused examples
- acknowledge contributors in release announcements
- encourage discussions in the community (i.e. minimise private team discussions)
Java Versions
- Support native JTA 2.0, EE 10 and Jakarta EE namespace: this work is already well under way. Java SE 11 is now the minimum runtime supported by WildFly and Jakarta EE compatible implementations.
- Remove support for Java SE 8 (i.e. SE 11 will the minimum supported version) and add support for Java SE 17
Integrating contemporary services:
- Kafka Integration
- Quarkus support for REST-AT. This task depends on SRA (aka REST-AT annotations) Tasks
Cloud strategy:
- Managed Transaction Service
- An improved cloud strategy for JTA around recovery (again we have already started work in this area). Currently we need to create a bespoke solution for every cloud, e.g. the WildFly kubernetes operator.
This task includes provision of a more “cloud ready” transaction log store.
The task still needs to be pinned down but some relevant input material includes:
- Transactional cloud resources (this includes an investigation of whether an Infinispan based store is feasible - note that earlier versions were incompatible with our needs)
- Investigate jgroups-raft and whether this can help with creating a cloud-ready object store
- Add clustering support
- Add an SPI nethod to obtain a unique identifier for a transaction
- No easy way to acquire the node name from the JBoss Transaction SPI
There is also the forum item: reliably generate node identifiers which will help with using Narayana in cloud deployments:
- the task should also explore the pros and cons of storing it for crash recovery purposes
- the forum thread also includes some work that we may do on validating our current uid solution for cloud environments
- Better integration of LRA in cloud environments:
Transaction Log Stores
- Persistent Memory: narayana already provides a pmem based object store which we would like to integrate into WildFly
- Journal Store performance improvements
- Provide a native file lock alternative to our own Object Store locking (FileLock.java) for managing concurrent access to a transaction log. It should be configurable at runtime or build time (Quarkus is a good use case). If the runtime platform does not provide the capability then a default fallback mechanism will be defined.
Upgrades/Deprecation/Removal/Replacement of existing functionality:
- Remove Transactional Driver in favour of using Agroal. We are tracking this work using JBTM-3439.
- Remove txframework - it was previously deprecated by the compensations module. The issue tracker is Remove old TXFramework API
- Remove support for JacORB which is now EOL
- Upgrade to JUnit 5 (from 4) for unit testing: Testing Narayana using JUnit 5
Other
- 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 section 3.5 Synchronous, Non-blocking and Asynchronous Modes, there are still things we would like to do in this area including Asynchronous JTA
