[jbossts-issues] [JBoss JIRA] (JBTM-1451) Transactional cloud storage

Paul Robinson (JIRA) jira-events at lists.jboss.org
Tue Jan 29 09:41:47 EST 2013


     [ https://issues.jboss.org/browse/JBTM-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Robinson updated JBTM-1451:
--------------------------------

    Description: 
Student project that we are not currently offering:

{quote}
Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution.

In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager.

This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source.
{quote}

  was:
Student project that we are not currently offering:

{quote}
Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM.  These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications.

This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source.
{quote}


    
> Transactional cloud storage
> ---------------------------
>
>                 Key: JBTM-1451
>                 URL: https://issues.jboss.org/browse/JBTM-1451
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Paul Robinson
>              Labels: student
>
> Student project that we are not currently offering:
> {quote}
> Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution.
> In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager.
> This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jbossts-issues mailing list