Version 49

    The list of current projects offered by the Narayana team can be found in our issue tracker by searching for issues which have both of the labels "student" and "available". You can easily take a look at the open projects using the following filter:

    Candidates are also welcome to propose their own topic by contacting us on IRC to discuss their ideas. Just to point out that we specialise in transactions and so as much as the team do pursue a broad set of interests, we can best contribute on projects with a transactional nature.


    Notes on Application Procedure

    Candidates should select a shortlist of project topics in which they have particular interest, in order that we can ensure their application is handled by the most appropriate software engineering staff. Notification of the preferred projects should be sent by email, along with a C.V. and some source code. All JBoss projects require competence in software engineering, so a body of work that demonstrates design, coding and testing skills is preferred. For postgraduate level candidates, the undergraduate final year project work may be most appropriate. Contributions to existing open source projects will also be considered favorably.  The provided source should be in Java, unless the selected project specifically calls for work in other languages.  The submission will be reviewed by the potential project supervisors and candidates whose work meets the required standard will be invited to a face to face technical interview.

    Please do note that all work produced will be open source.



    Previous Projects


    Transactions and NoSQL Review

    This project was undertaken by Simon during 2014.

    When initial NoSQL solutions emerged, they came with limited support for transactions. Many people in the community claimed that ACID transactions would harm scalability and that it was better to architect the application in such a way as to not need them. However, as NoSQL solutions are being applied more broadly, it is becoming clear that many applications do indeed need a level of reliability that transactions can bring. As a result many vendors are starting to offer various transaction options. These options vary from traditional ACID transactions which are simpler to use but have scaling limitations, through to relaxed ACID options which tend to be more complex to use, but don't have the scalability limitations. Understanding what options are available and which to use, is a complex problem.


    This project will provide a useful reference for developers and architects who need the guarantees that transactions can bring, but don't know which model is right for them. In particular the project will:


    1) Review each of the transaction options available in NoSQL.

    2) Compare ACID and Extended (relaxed ACID) transaction models and understand how these models relate to NoSQL and scalability.

    3) Implement performance tests for a selection of transaction options under different classes of workload. Initially on a single node, and later on a cluster of machines.


    To undertake this project you should be capable of understanding the theory behind ACID and Extended transactions. You will also need to be able to setup multiple NoSQL environments and develop a suite of performance tests for them. Critical analysis of these results will be essential.



    Scaling a transaction manager in the Cloud

    This project was undertaken by James Brealey during 2014.

    Transaction coordination systems such as Narayana rely upon storage facilities to recreate transaction state during recovery from a system crash. These logs are usually stored on RAID hard drives to maximize reliability. However, any disk I/O is relatively slow and writing the logs can become a bottleneck in high performance transaction systems. Using the fastest available disk subsystems is thus an expensive necessity for many enterprise applications.


    The use of a cluster of inexpensive, unreliable hardware nodes in conjunction with data replication for redundancy is an increasingly popular and cost effective architecture for many highly scalable, high reliability applications. Data grids such as Infinispan provides distributed in-memory replication of Java objects, making programming for this kind of cluster relatively simple.


    In this project you will implement a transaction logging plugin for Narayana that uses a data grid to replicate the logs to main memory on other nodes in a cluster, in preference to writing them to disk. You will then devise tests to benchmark this approach against the existing plugins that Narayana offers. You may also research reliability statistics for large clusters to determine the degree of reliability and availability each of these approaches offers. This will allow customers to make a well informed architecture decision with regard to the cost/performance/reliability tradeoffs of the different logging options.


    To undertake this project you should have a good understanding of Java and some appreciation of distributed systems architecture. Stronger candidates will have some background in at least one of the following: transaction systems, group communication, multicast or replication, performance benchmarking and tuning. A solid grasp of math, including basic probability and statistics, is essential. The work will be open source.


    Realtime Monitoring and Analysis of Transactions

    This project was undertaken by Alex Creasy during 2013. It resulted in a distinction level mark. Alex took a job with Red Hat shortly after completing his project.

    Alex's project is now under active development and the source code can be found here:

    In a modern high-throughput system, running many concurrent transactions, it can be difficult to analyse the performance and success of individual transactions. Current approaches require a high level of knowledge of the underlying transaction system and also struggle to scale as the number of concurrent transactions increase.


    Through this project, a tool will be created to analyse transactions either at runtime or from a static log. Transactions can fail for many reasons, including; heuristic decisions, system failure and transaction timeouts. The tool will be able to diagnose these issues and present them to the user in an easily understood format. The tool should provide detailed information on each transaction; such as which resources where involved, what servers a distributed transaction passed through and what type of transaction was in play. Other information, such as transaction duration and timestamps could also be displayed. The tool could also provide a facility for querying the data to help diagnose particular issues.


    To complete this project, the successful student would be expected to gain deep knowledge in the theory of transactions and develop a good understanding of how JBoss Transactions works under the covers. Also, as the project itself could consume much more time than is available for the project, the student would be expected to identify an area of focus which could be tailored to their particular expertise.


    RESTful transaction bridge

    This project was undertaken by Gytis Trikleris during 2012. It resulted in a distinction level mark and Gytis now works for Red Hat. Newcastle Uni students can probably find a copy in the library.


    The REST architectural style is a popular choice for web services and widely regarded as simpler than many alternatives. The REST approach is not a silver bullet to reducing complexity though. It does nothing to remove the need for security, transactions and other 'enterprise' considerations. Indeed implementation of these is made in some ways more difficult by the lack of applicable standards in REST when compared to the more SOAP focused WS- protocols e.g. WS-AT and WS-BA.


    A prototype implementation of a RESTful transaction coordination protocol already exists. However, the API is low-level and integrating with existing transactional business logic e.g. EJB3, presents a significant challenge to users.


    In this project you will consider how to provide middleware support for transactional REST based web services which integrate with existing transacitonal JEE business logic components such as EJBs. The lessons learned from JSR-181, JAX-RS and the existing WS-AT/JTA transaction bridge will likely be relevant, but substantial scope exists for new contributions in this field.


    You will make such contribution in the form of new middleware to help developers in this area, and will validate your solution by implementing a demo application and interacting with the early adopter community.


    To undertake this project you should have a solid understanding of different web services architectures (e.g. SOAP, REST) and some understanding of transactions, particularly existing standards for JEE and web services transactions (e.g. JTA, XA, WS-AT). The work will be open source.


    Memory resident transactional objects

    This project was done by Jeremy Whiting during 2009. It resulted in a distinction level mark and Jeremy now holds a senior position at Red Hat. Newcastle Uni students can probably find a copy in the library.


    Further notes


    The ability to manipulate a system's state in a transactional manner is fundamental to much enterprise programming. In Java this is supported mainly by EJBs, objects whose canonical state is stored in a relational database and manipulated via a transient in-memory representation. This model is well standardized and widely supported by application servers. Nevertheless, it has significant drawbacks, particularly in regard of performance and scalability. Many large systems are instead moving to memory backed state, with replication for availability and disk based storage only for backup. Support for transactional updates in such an environment is frequently lacking, due to the perceived drawbacks of a lock based model with regard to scalabilty and availability.


    In this project you will investigate ways to provide transactional manipulation of object state, where that state is either in-process (i.e. POJOs) or memory resident but accessed via some remoting protocol (e.g. memcached, distributed JBossCache). Multi version concurrency control and optimistic locking techniques will likely be relevant, as will use of annotations and AOP to make the operation as unobtrusive as possible to users. We seek a soluton to occupy the middle ground between language level software transactional memory and database backed storage. The ability to configure for full ACID semantics, eventual consistency or various levels in between would be desirable. In the case of ACID transactions, it sould be possible for the system to operate as an XA compliant resource manager, to facilitate interoperation with existing transactional components.


    To undertate this project you should be comfortable programming in Java and have some experence of and interest in a majority of the following: transactional business logic (e.g. EJBs), transaction protocols, relational databases, caching and replication systems (e.g. memcached, JGroups), design of highly available and highly scalable systems, aspect oriented programming. The work will be open source.


    Meta-data support for Transactional Web Services

    This project was done by Maciej Machulak during 2007. Newcastle Uni students can probably find a copy in the library. It resulted in a distinction level mark and an international workshop presentation.

    See for the results


    The Java EE specification provides substantial support for declarative configuration and management of traditional ACID transactions. Using EJB3 entity beans to wrap access to  transactional resources (databases, message queues) is  relatively simple, with many low level concerns (resource  enlistment, concurrency control, ...) being well  masked from the business programmer by the application  server and resource managers. Transactional Web Services,  being a much more recent model, lack such support. Writing a  transaction aware Web Service requires the business  programmer to concern themselves with many low level details  that would be better handled by the middleware tier. In this  project you will develop a suite of tools, perhaps including  annotations or new APIs, to enhance the capabilities of an  existing web services transaction manager and ease the task  of writing transactional Web services.


    To undertake this project you should have a good  understanding of Web services and some knowledge of Java EE  transaction support, including EJB3. Prior knowledge of Web  Services transaction standards would be beneficial but is  not required. The work will be open source.


    Transactional File I/O in Java.

    This project was done by Ioannis Ganotis during 2008. Newcastle Uni students can probably find a copy in the library.

    See for the results


    Further notes


    Transactions are often used to structure activities within  reliable software applications. In Java EE, business logic  typically involves accessing transactional resource managers  (databases, message queues) within boundaries denoted by  calls to the JTA (begin/commit/rollback). The resource  managers work with the transaction manager to perform e.g.  locking, logging and recovery transparently to the  application programmer. However, this separation of concerns  is broken with regard to one important resource: the file  system.  Java's file I/O library does not support  transactions, a situation which requires application  programmers to implement such support manually in their  programs.  In this project you will develop a transaction  aware resource manager for file I/O in Java. This library  will provide application programmers with access to a  filesystem that offers ACID semantics.


    To undertake this project you should have a good  understanding of Java file I/O and some knowledge of  transactions (ACID semantics and the JTA). The work will be  open source.


    IDE support for Byteman Rules

    This project was done by Rebecca Simmonds during 2011 and resulted in a distinction level mark. Rebecca is now enrolled in a PhD sponsored by Red Hat. Newcastle Uni students can probably find a copy in the library.


    Byteman is a JBoss hosted project which provides support for testing and debugging of Java programs via injection of side effects. Byteman employs Event Condition Action rules to define where, whether and what side effects should be inserted into application (or JVM) code. These rules are organized into scripts which are loaded either at program boot time or during program execution. Byteman provides a java agent which transforms the target method bytecode so as to incorporate the desired side effects.


    This project involves developing an IDE plugin to manage a project's Byteman rule base, simplifying the tasks of:

    • creating rules
    • correlating rules with the target methods to which they apply
    • loading rules into the application's runtime environment at startup or during execution
    • tracking rule transformation, compilation and execution


    Although this project is offered by the JBossTS team, no specific knowledge of transactions is involved. No IDE is prescribed but the most useful candidates would be either Eclipse or IntelliJ IDEA (both these IDEs provide a comprehensive and well-documented plugin development API).  Detailed knowledge of the byteman implementaton and bytecode transformation will not be required. The work will be open source.