[JBoss JIRA] (JBTM-1495) Merge in BlackTie
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-1495:
-----------------------------------
Summary: Merge in BlackTie
Key: JBTM-1495
URL: https://issues.jboss.org/browse/JBTM-1495
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Build System
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.Final
Docs, code, forums, chat room (motd), Jira, web pages
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1450) Transaction processing in javascript
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1450?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1450:
--------------------------------
Reporter: jhalli (was: Paul Robinson)
> Transaction processing in javascript
> ------------------------------------
>
> Key: JBTM-1450
> URL: https://issues.jboss.org/browse/JBTM-1450
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: jhalli
> Labels: student
>
> 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}
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1451) Transactional cloud storage
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1451?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1451:
--------------------------------
Reporter: jhalli (was: Paul Robinson)
> 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: jhalli
> 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
11 years, 2 months
[JBoss JIRA] (JBTM-1449) Transactions in the browser
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1449?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1449:
--------------------------------
Reporter: jhalli (was: Paul Robinson)
> Transactions in the browser
> ---------------------------
>
> Key: JBTM-1449
> URL: https://issues.jboss.org/browse/JBTM-1449
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: jhalli
> Labels: student
>
> Student project that we are not currently offering:
> {quote}
> Recent developments in web standards (HTML5, specifically Web Storage a.k.a. DOM Storage) indicates a move towards widespread availability of client (i.e. web browser) side persistent storage accessible by web applications. Initially useful for making content and applications available offline, this also open up the possibility of object replication between client and server. In this project you will explore the applicability of transaction concepts to applications built on this model. In particular, you will focus on identifying and exploiting new opportunities made available by the existence of persistent storage on the browser, a vital pre-requisite for recoverable transactions.
> To undertake this project you should have a strong interest in web based applications, some javascript programming experience and a basic understanding of transactions concepts. Previous experience of at least one javascript framework would be an advantage. 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
11 years, 2 months
[JBoss JIRA] (JBTM-1468) Support pure-JTA client and server for WS-AT and REST-AT
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1468?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1468:
--------------------------------
Component/s: REST
XTS
> Support pure-JTA client and server for WS-AT and REST-AT
> --------------------------------------------------------
>
> Key: JBTM-1468
> URL: https://issues.jboss.org/browse/JBTM-1468
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: REST, XTS
> Reporter: Paul Robinson
>
> This allows the Client and server application to just use the JTA APIs, whilst having the distribution done over WS-AT or REST-AT.
> To do this we need to:
> # Remove @Transactional annotation. We then need to use some other mechanism to support the (optional) WS-AT participants that want to use annotations.
> # Client side JTA->REST-AT bridge. Needs implementing.
> # Server side REST-AT->JTA bridge. Needs integrating into code base.
> # Update the TXBridge quickstarts to use this and move them out.
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1481) Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1481?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1481:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/224
> Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1481
> URL: https://issues.jboss.org/browse/JBTM-1481
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTS, Transaction Core
> Affects Versions: 4.6.1.CP13
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 4.6.1.CP14, 4.16.7, 4.17.4, 5.0.0.M2
>
> Attachments: JBTM-1481.patch, WedgedResourceDemonstrator.java
>
>
> If you are getting a wedged resource. What then happens is that we interrupt the original reaper thread that is calling XAResource::rollback on the wedged resource which because you are using JacORB and have an in progress call will generate a null pointer exception when the thread is interrupted (you can see this in my attached log file, it prints a stack trace where the logging didn't do so before) which generates a org.omg.CORBA.TRANSACTION_ROLLEDBACK exception.
> The problem is that after the reaper tries to rollback the transaction but stalls on a wedged resource, it is then possible for the app thread to unwedged and to do a JTA::commit() and not get an exception. Debugging through the code, it doesn't pose data integrity issues on the transaction as what is happening is that internally we are checking the status of the transaction:
> ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:340
> And because the transaction is not RUNNING or ABORT_ONLY, we are:
> ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:398:
> throw new INVALID_TRANSACTION(0, CompletionStatus.COMPLETED_NO)
> Which is all good so far but then ends up in:
> ./ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java:1425
> catch (INVALID_TRANSACTION e6)
> {
> /*
> * In JTS/OTS we can indicate that something was terminated by another thread.
> * JTA doesn't really prevent this, but ...
> */
>
> //throw new IllegalStateException(
> // jtaLogger.loggerI18N.getString("com.arjuna.ats.internal.jta.transaction.jts.invalidtx2"));
> }
> Where it appears at some point we would have thrown an exception but decided to make the call that this was not valid anymore.
> As I say, it doesn't pose data integrity implications to the specific transaction, but if your app thread unwedges and you then make a decision on the outcome of the transaction (send email, acknowledge success) then it would break the business rules of that application.
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1494) Produce performance figures to show improvement of using WS-BA over WAN
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1494:
-----------------------------------
Summary: Produce performance figures to show improvement of using WS-BA over WAN
Key: JBTM-1494
URL: https://issues.jboss.org/browse/JBTM-1494
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: XTS
Reporter: Paul Robinson
As part of evangelising compensations, it would be useful to show the performance comparisons for an application distributed over the internet.
Ideally, these results should show that that the performance of WS-BA is a lot better than WS-AT. Also it would be good to show that the overhead of using WS-BA over not using it, is relatively small compared to the benefits of guarantees it gives.
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1468) Support pure-JTA client and server for WS-AT and REST-AT
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1468?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1468:
--------------------------------
Issue Type: Enhancement (was: Feature Request)
> Support pure-JTA client and server for WS-AT and REST-AT
> --------------------------------------------------------
>
> Key: JBTM-1468
> URL: https://issues.jboss.org/browse/JBTM-1468
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Paul Robinson
>
> This allows the Client and server application to just use the JTA APIs, whilst having the distribution done over WS-AT or REST-AT.
> To do this we need to:
> # Remove @Transactional annotation. We then need to use some other mechanism to support the (optional) WS-AT participants that want to use annotations.
> # Client side JTA->REST-AT bridge. Needs implementing.
> # Server side REST-AT->JTA bridge. Needs integrating into code base.
> # Update the TXBridge quickstarts to use this and move them out.
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-861) Enhance XTS AS7 configuration
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-861?page=com.atlassian.jira.plugin.s... ]
Paul Robinson updated JBTM-861:
-------------------------------
Issue Type: Enhancement (was: Feature Request)
> Enhance XTS AS7 configuration
> -----------------------------
>
> Key: JBTM-861
> URL: https://issues.jboss.org/browse/JBTM-861
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.15.2
> Reporter: Andrew Dinn
> Priority: Minor
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-861) Enhance XTS AS7 configuration
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-861?page=com.atlassian.jira.plugin.s... ]
Paul Robinson commented on JBTM-861:
------------------------------------
It's AS code only. Moving...
> Enhance XTS AS7 configuration
> -----------------------------
>
> Key: JBTM-861
> URL: https://issues.jboss.org/browse/JBTM-861
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.15.2
> Reporter: Andrew Dinn
> Priority: Minor
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.
--
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
11 years, 2 months