[JBoss JIRA] (JBTM-845) Cloud ObjectStore
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-845?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson commented on JBTM-845:
------------------------------------
I revised the subject wording on JBTM-1451.
This Jira is about e.g. a jgroups/infinispan object store, JBTM-1451 is about defining an XA like resource management API for "cloud" datasources/resources.
> Cloud ObjectStore
> -----------------
>
> Key: JBTM-845
> URL: https://issues.jboss.org/browse/JBTM-845
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Recovery
> Reporter: Tom Jenkinson
>
> Create an objectstore that uses infinispan or jgroups for replication of volatile data
--
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, 8 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:
--------------------------------
Summary: Transactional cloud resources (was: Transactional cloud storage)
> 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)
> 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, 8 months
[JBoss JIRA] (JBTM-1414) Facilitate TM record removal by adding record's file name to the warning message
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1414?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-1414.
---------------------------------
Resolution: Won't Fix
See comments
> Facilitate TM record removal by adding record's file name to the warning message
> ---------------------------------------------------------------------------------
>
> Key: JBTM-1414
> URL: https://issues.jboss.org/browse/JBTM-1414
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Recovery
> Environment: JBoss EAP 6.x
> Reporter: Tom Ross
>
> When printing warnings about none recoverable transaction manager records in the object store it would help if the warning message included the record's physical file name as well. It would made the manual removal of those records much easier.
> {noformat}
> 15:19:51,003 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a2c0a0d:-140df526:50d1ddd3:ac883, node_name=1, branch_uid=0:ffff0a2c0a0d:-140df526:50d1ddd3:ac95c, subordinatenodename=null, eis_name=java:jboss/eis/Connection >, heuristic: TwoPhaseOutcome.FINISH_OK, product: ActiveMQ/5.7.0, jndiName: java:jboss/eis/Connection com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@5e124b >
> 15:19:51,008 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a2c0a0d:-140df526:50d1ddd3:ac883, node_name=1, branch_uid=0:ffff0a2c0a0d:-140df526:50d1ddd3:ac95c, subordinatenodename=null, eis_name=java:jboss/eis/Connection >
> {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, 8 months
[JBoss JIRA] (JBTM-1284) Optionally circumvent ThreadAction in ArjunaCore when using concurrent nested transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1284?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1284:
--------------------------------
Summary: Optionally circumvent ThreadAction in ArjunaCore when using concurrent nested transactions (was: Implement concurrent nested transactions)
> Optionally circumvent ThreadAction in ArjunaCore when using concurrent nested transactions
> ------------------------------------------------------------------------------------------
>
> Key: JBTM-1284
> URL: https://issues.jboss.org/browse/JBTM-1284
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Tom Jenkinson
>
> Needs sanity checking
> We can collaborate on the work via linked GitHub branch
> The problem out of the box is when you AtomicAction "begin" - you will link to the ThreadActionData, as you can see in the test I can circumvent that via a different API call start passing in the parent directly.
> You can see there is precedent to manipulate ThreadActionData: ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AsyncPrepare.java (doing the prepare in multiple threads)
> I think this is feasible, it may need some thread safety via synchronization in the AtomicAction.
> Nested Transactions in core look to be able to support concurrent access except:
> 1. Threading may not work, will need to check and fix
> 2. ThreadActionData imposes a stack
> You can see in my test (linked in the GitHub branch) I am circumventing the stack.
> we already support nested transactions, it should just be not associating them with a thread and making sure they are thread safe when they talk to their parents
--
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, 8 months
[JBoss JIRA] (JBTM-1516) XTS: Common configuration is not available
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1516?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1516:
-------------------------------------
To Reproduce:
Put a break point in org.jboss.ws.common.management#addClientConfig() and tell the debugger not to suspend other threads. This causes JBossWS to suspend startup just before it adds the CommonConfig. XTS should wait for this to finish, but it doesn't. You then get the stacktrace when XTS can't find the CommonConfig.
> XTS: Common configuration is not available
> ------------------------------------------
>
> Key: JBTM-1516
> URL: https://issues.jboss.org/browse/JBTM-1516
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Application Server Integration, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Critical
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 hour
> Time Spent: 40 minutes
> Remaining Estimate: 1 day
>
> See:
> http://172.17.131.2/view/Narayana+BlackTie/job/narayana/180/artifact/txfr...
> Only happened for one test. Looks like an intermittent failure. If there was anything wrong with the config, it would fail for all tests.
--
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, 8 months