[JBoss JIRA] (JBTM-1700) Server startup is delayed if recovery starts before all resource plugins register
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1700?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1700:
--------------------------------
Component/s: JTA
Recovery
> Server startup is delayed if recovery starts before all resource plugins register
> ---------------------------------------------------------------------------------
>
> Key: JBTM-1700
> URL: https://issues.jboss.org/browse/JBTM-1700
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA, Recovery
> Reporter: James Livingston
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.M4
>
>
> If the startup of JBoss is sufficiently slow, it is possible for a recovery run to already be in progress when a resource plugin is added. When this occurs, the startup will block until the recovery run has finished.
> It would be much better if starting a recovery run did not block AS startup.
> An example of this occurring on EAP 5 is:
> "main" prio=10 tid=0x00002aac680cc000 nid=0x5e67 waiting for monitor entry [0x00000000412cb000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.addXAResourceRecoveryHelper(XARecoveryModule.java:85)
> - waiting to lock <0x00002aab3e8b9d68> (a java.util.LinkedList)
> at com.arjuna.ats.jbossatx.jta.TransactionManagerService.addXAResourceRecovery(TransactionManagerService.java:695)
> at org.jboss.resource.connectionmanager.ManagedConnectionFactoryDeployment.startService(ManagedConnectionFactoryDeployment.java:500)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322)
> at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:124)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:283)
> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:189)
> at $Proxy43.start(Unknown Source)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> ...
> "Thread-21" prio=10 tid=0x00002aacdd1f7000 nid=0x5ee3 runnable [0x000000004416a000]
> java.lang.Thread.State: RUNNABLE
> ...
> at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:294)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:773)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:712)
> - locked <0x00002aab3e8b9d68> (a java.util.LinkedList)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:201)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)
--
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, 3 months
[JBoss JIRA] (JBTM-1820) Integrate with Camel to support XA Transaction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1820?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1820:
--------------------------------
Component/s: Application Server Integration
> Integrate with Camel to support XA Transaction
> ----------------------------------------------
>
> Key: JBTM-1820
> URL: https://issues.jboss.org/browse/JBTM-1820
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Application Server Integration
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
>
> From Ning Jiang (njiang(a)redhat.com)
> {noformat}
> Camel is using Spring TransactionTemplates to implement the Transactional Client pattern[1].
> As the Spring PlatformTransactionManager cannot manage the multiple resources, we are using the atomikos to show the user how to manage the transactions between JMS and DB resource. It could great if we can replace the atomikos with narayana, then we can promote this example as reference to SA who can sale the solution to the customer.
> Another interesting task could be using the narayana JTA wrapper classes to replace the Spring TransactionTemplate in Camel. As we don't want to build out products on top of Spring framework, using narayana could help us to get ride of Spring and introduce the narayana to integration customer.
> [1]http://camel.apache.org/transactional-client.html
> {noformat}
--
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, 3 months
[JBoss JIRA] (JBTM-1449) Transactions in the browser
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1449?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1449:
--------------------------------
Component/s: Student project
> 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)
> Components: Student project
> Reporter: jhalli
> Labels: student
> Fix For: 6.0.0.Final
>
>
> 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, 3 months
[JBoss JIRA] (JBTM-1450) Transaction processing in javascript
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1450?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1450:
--------------------------------
Component/s: Student project
> 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)
> Components: Student project
> Reporter: jhalli
> Labels: student
> Fix For: 6.0.0.Final
>
>
> 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, 3 months
[JBoss JIRA] (JBTM-1451) Transactional cloud resources
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1451?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1451:
--------------------------------
Component/s: Student project
> Transactional cloud resources
> -----------------------------
>
> 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)
> Components: Student project
> 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, 3 months
[JBoss JIRA] (JBTM-1705) Remove XTS CDI Extension
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1705?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1705:
--------------------------------
Component/s: XTS
> Remove XTS CDI Extension
> ------------------------
>
> Key: JBTM-1705
> URL: https://issues.jboss.org/browse/JBTM-1705
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Critical
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> WFLY-1370 removes the need for the CDIExtensionProcessor in the XTS subsytem.
> There is currently a hack in CDIExtensionProcessor in 5_BRANCH. This MUST be removed if WFLY-1370 is not merged in time for release. Hence I have marked this as critical.
--
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, 3 months