July 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1052) Support Web services with a webservices.xml present in TXFramework

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1052?page=com.atlassian.jira.plugin.... ] Gytis Trikleris closed JBTM-1052. --------------------------------- Fix Version/s: (was: 6.later) Resolution: Rejected > Support Web services with a webservices.xml present in TXFramework > ------------------------------------------------------------------ > > Key: JBTM-1052 > URL: https://issues.jboss.org/browse/JBTM-1052 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: TXFramework > Reporter: Paul Robinson > Priority: Minor > > See: https://community.jboss.org/message/714478#714478 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1167) WS-BA TXFramework quickstart should use @ConfirmCompleted to send email

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1167?page=com.atlassian.jira.plugin.... ] Gytis Trikleris closed JBTM-1167. --------------------------------- Resolution: Rejected > WS-BA TXFramework quickstart should use @ConfirmCompleted to send email > ----------------------------------------------------------------------- > > Key: JBTM-1167 > URL: https://issues.jboss.org/browse/JBTM-1167 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Paul Robinson > Priority: Minor > Original Estimate: 1 day > Remaining Estimate: 1 day > > There is a bug in this quickstart. The email is sent in the 'placeOrder' method. If a crash occurs after the email is sent, but before XTS writes the recovery record, then a compensate will not be triggered. You should wait until an @ConfirmCompleted method is invoked (with parameter of 'true') is invoked. This is confirmation that the XTS recovery record was written and a final outcome is guaranteed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1715) NPE when using CompensationManager within an in-flowed WS-BA transaction

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1715?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1715: ---------------------------------- Component/s: Compensations (was: TXFramework) > NPE when using CompensationManager within an in-flowed WS-BA transaction > ------------------------------------------------------------------------ > > Key: JBTM-1715 > URL: https://issues.jboss.org/browse/JBTM-1715 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The following error occurs if an injected CompensationManager is invoked within the scope of a compensation-based transaction that was in-flowed via a WS-BA transaction. > {quote} > 16:17:09,879 ERROR [org.jboss.as.ejb3.invocation] (default task-18) JBAS014134: EJB Invocation failed on component TestServiceService for method public void org.jboss.narayana.compensations.functiona[617/9100] > ted.TestServiceService.saveDataCancelOnFailure(java.lang.Boolean): javax.ejb.EJBException: java.lang.NullPointerException > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:215) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPS > HOT] > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2629: -------------------------------- Component/s: Transactional Driver > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1718) Resolve the ParticipantCompletion race condition

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1718?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1718: ---------------------------------- Component/s: Compensations (was: TXFramework) > Resolve the ParticipantCompletion race condition > ------------------------------------------------ > > Key: JBTM-1718 > URL: https://issues.jboss.org/browse/JBTM-1718 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Paul Robinson > > This issue is documented here: JBTM-1429 > In the documentation for JBTM-1429, we state that this issue is unlikely to happen in a distributed environment. This is true, however, the Compensations API is designed to work local-only as well as distributed over WS-BA. Therefore it is much more likely to happen in a production environment. > Therefore we need to remove this race condition. It can be done in a proprietary mannor as we are not interoperating with another implementation ion local-only mode. When distributing the transaction we fall back to the standard protocol that is susceptible to the race condition. However, as we stated in the docs, this condition is unlikely to manifest in a distributed environment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1030) Async commit feature in TXFramework

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1030?page=com.atlassian.jira.plugin.... ] Gytis Trikleris closed JBTM-1030. --------------------------------- Resolution: Rejected > Async commit feature in TXFramework > ----------------------------------- > > Key: JBTM-1030 > URL: https://issues.jboss.org/browse/JBTM-1030 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework > Reporter: Paul Robinson > Priority: Minor > > It would be handy to provide an asynchronous commit feature. This would allow a thread to continue whilst the transaction protocol proceeds. A callback handler can be registered to handle the outcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-979) Support REST-JDI protocol in the TXFramework

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-979?page=com.atlassian.jira.plugin.s... ] Gytis Trikleris closed JBTM-979. -------------------------------- Fix Version/s: (was: 6.later) Resolution: Rejected > Support REST-JDI protocol in the TXFramework > --------------------------------------------- > > Key: JBTM-979 > URL: https://issues.jboss.org/browse/JBTM-979 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework > Reporter: Paul Robinson > Priority: Optional > Labels: TXFramework > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1680) Allow 2PC participants to enlist in a compensation-based transaction

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1680?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1680: ---------------------------------- Component/s: Compensations (was: XTS) (was: TXFramework) > Allow 2PC participants to enlist in a compensation-based transaction > -------------------------------------------------------------------- > > Key: JBTM-1680 > URL: https://issues.jboss.org/browse/JBTM-1680 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.later > > Original Estimate: 1 week > Remaining Estimate: 1 week > > In some situations a developer may need to coordinate multiple resources, where some are 2PC and some are not. Here it could be possible to use enlist the 2PC participants in a compensation-based transaction. The xa.prepare happens in the complete phase, the xa.commit during close and xa.rollback during compensate. > This could provide an alternative to LRCO, where the last resource is compensation-based and the other resources remain 2PC. The benefit of this approach is that the failure window associated with LRCO does not exist. The negative of this approach is that the isolation of the compensation-based participant is reduced. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1576) Introduce a JBoss deployable artifact for the C++ XATMI services

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1576?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1576: -------------------------------- Priority: Minor (was: Major) > Introduce a JBoss deployable artifact for the C++ XATMI services > ---------------------------------------------------------------- > > Key: JBTM-1576 > URL: https://issues.jboss.org/browse/JBTM-1576 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie > Reporter: Tom Jenkinson > Priority: Minor > Attachments: onmessage.tgz > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently the XATMI services must be deployed in the standalone "Server" CORBA container > It is expected to be advantageous to support the deployment of the services into JBoss for ease of management and performance. > It is expected that the user will deploy a .war file containing a btconfig.xml defining the .so/.dll (also contained in the .war). > BlackTie java code will read the btconfig.xml and calculate the path of the .so based on the place that AS7 unzips war files to during deployment PLUS the path defined in the users btconfig.xml > If AS7 does not explode war files during deployment, it will not be possible for the user to package their .so in their .war file (I don't think - please do investigate this) and so a java.native.library.path will need defining at boot time and the user will need to place all their jni code in there thereby not supporting hot deploy unfortunately but still gaining the benefits of performance (not requiring socket comms between java and C). > Cache the JNIEnv* to use to callback on the datasources - Allow C++ XATMI services deployed into the AS to use the existing JCA connections -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1576) Introduce a JBoss deployable artifact for the C++ XATMI services

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1576?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1576: -------------------------------- Component/s: (was: Tooling) > Introduce a JBoss deployable artifact for the C++ XATMI services > ---------------------------------------------------------------- > > Key: JBTM-1576 > URL: https://issues.jboss.org/browse/JBTM-1576 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie > Reporter: Tom Jenkinson > Attachments: onmessage.tgz > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently the XATMI services must be deployed in the standalone "Server" CORBA container > It is expected to be advantageous to support the deployment of the services into JBoss for ease of management and performance. > It is expected that the user will deploy a .war file containing a btconfig.xml defining the .so/.dll (also contained in the .war). > BlackTie java code will read the btconfig.xml and calculate the path of the .so based on the place that AS7 unzips war files to during deployment PLUS the path defined in the users btconfig.xml > If AS7 does not explode war files during deployment, it will not be possible for the user to package their .so in their .war file (I don't think - please do investigate this) and so a java.native.library.path will need defining at boot time and the user will need to place all their jni code in there thereby not supporting hot deploy unfortunately but still gaining the benefits of performance (not requiring socket comms between java and C). > Cache the JNIEnv* to use to callback on the datasources - Allow C++ XATMI services deployed into the AS to use the existing JCA connections -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues July 2016