October 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2997) Ensure that any LRA coordinator can control any LRA

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2997?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2997: ---------------------------------------- Here are some notes I added about different coordinators accessing the same LRA record: Up until the time that the state moves to Compensating/Compensated anyone should be able to update an LRA record. After that we need to assign an owner (ie the coordinator that is driving the termination phase) and there needs to be a component that monitors that owners progress (assigning a new owner if it it fails). I don't think we need to worry about things like network partitions since the participant callbacks are meant to be idempotent. In recovery scenarios I would just write a timestamp into the record on each recovery pass and monitor that. In fact the presence of that timestamp would imply that there is a current owner and other coordinators need to leave it alone and only take over if it stops being updated. To summarise, I would just write the owner/timestamp into the record when the state change is written and periodically update it thereafter. Any other coordinator that gets a request to close/cancel the LRA (this includes period recovery) should only take control if the owner/timestamp stops being updated. Since STM/LockRecords ought to work for all store types I think we should definitely consider their use. > Ensure that any LRA coordinator can control any LRA > --------------------------------------------------- > > Key: JBTM-2997 > URL: https://issues.jboss.org/browse/JBTM-2997 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.8.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > Currently the management of an LRA is restricted to the coordinator that created it. It would be preferable to have the option of allowing any coordinator be able to manage any LRA. The motivation for this feature is to enhance the usability of LRAs in cloud based environments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3059) Move the JAX-RS specific parts of the LRA API into a separate API

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3059?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-3059. ---------------------------------- Resolution: Rejected The upstream issue (https://github.com/eclipse/microprofile-lra/issues/18) was rejected essentially because it is expected that MP implementations can rely on JAX-RS and separating out the JAX-RS dependencies, if needed, is best addressed in a later revision of the spec. > Move the JAX-RS specific parts of the LRA API into a separate API > ----------------------------------------------------------------- > > Key: JBTM-3059 > URL: https://issues.jboss.org/browse/JBTM-3059 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > To ensure that the LRA APIs have broader applicability the JAX-RS specific aspects of the API need to be pulled out into a separate section. This change will mean it is possible to provide implementations of the API using non JAX-RS transports (such as gRPC etc). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3066) Starting a nested LRA via the client API leaves the parent as the current context

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3066?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3066: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Starting a nested LRA via the client API leaves the parent as the current context > --------------------------------------------------------------------------------- > > Key: JBTM-3066 > URL: https://issues.jboss.org/browse/JBTM-3066 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If an LRA is associated with a thread and that thread then starts a new LRA then the new one is nested under the first. When using the LRAClient API to start the child LRA the resulting context is left as the parent. This is wrong since the thread should now operate in the context of the nested LRA. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3063) Include a simple LRA quickstart showing difference between using a proxy and CDI

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3063?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3063: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Include a simple LRA quickstart showing difference between using a proxy and CDI > -------------------------------------------------------------------------------- > > Key: JBTM-3063 > URL: https://issues.jboss.org/browse/JBTM-3063 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Participants can join LRAs either via [annotations|https://github.com/eclipse/microprofile-lra/tree/master/api/s...] or via [a registration API|https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/...]. There should be a simple quickstart that demonstrates the difference between the two options. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3071) Windows automation of the LRA examples quickstarts

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3071: -------------------------------------- Summary: Windows automation of the LRA examples quickstarts Key: JBTM-3071 URL: https://issues.jboss.org/browse/JBTM-3071 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Affects Versions: 5.9.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The LRA examples quickstarts (https://issues.jboss.org/browse/JBTM-3063) contain a bash script to run the examples. We need the equivalent for running on Windows. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3070) Quickstart for transaction driver should not be using reflection

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3070?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3070: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Quickstart for transaction driver should not be using reflection > ---------------------------------------------------------------- > > Key: JBTM-3070 > URL: https://issues.jboss.org/browse/JBTM-3070 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > Currently the quickstart of transaction driver standalone uses reflection for forcibly closing H2 connection. It was used as a way to overcome the H2 issues with XA connection. > As the quickstart tests recovery it arbitrary throws an exception. This makes issue for H2 as it consider the connection as unfinished but if we close it it does not care and sets autocommit to true and let all the changes being immediately propagated to database. > That's what we don't want as we test recovery and we expect recovery to finish the in-doubt data. > The issue is only for H2 behaviour. "Normal" databases as PostgreSQL makes checks on unfinished transaction in jdbc driver and their decisions are based on it. > Nevertheless using reflection is not a good habit and it's a hacky. For quickstarts it should not be the case. There needs to be a way how to avoid it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3070) Quickstart for transaction driver should not be using reflection

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3070?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3070: ---------------------------------- Summary: Quickstart for transaction driver should not be using reflection (was: Quickstart for transaction driver should not use reflection) > Quickstart for transaction driver should not be using reflection > ---------------------------------------------------------------- > > Key: JBTM-3070 > URL: https://issues.jboss.org/browse/JBTM-3070 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > Currently the quickstart of transaction driver standalone uses reflection for forcibly closing H2 connection. It was used as a way to overcome the H2 issues with XA connection. > As the quickstart tests recovery it arbitrary throws an exception. This makes issue for H2 as it consider the connection as unfinished but if we close it it does not care and sets autocommit to true and let all the changes being immediately propagated to database. > That's what we don't want as we test recovery and we expect recovery to finish the in-doubt data. > The issue is only for H2 behaviour. "Normal" databases as PostgreSQL makes checks on unfinished transaction in jdbc driver and their decisions are based on it. > Nevertheless using reflection is not a good habit and it's a hacky. For quickstarts it should not be the case. There needs to be a way how to avoid it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3070) Quickstart for transaction driver should not use reflection

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3070?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondra Chaloupka created pull request #240 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Quickstart for transaction driver should not use reflection > ----------------------------------------------------------- > > Key: JBTM-3070 > URL: https://issues.jboss.org/browse/JBTM-3070 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > Currently the quickstart of transaction driver standalone uses reflection for forcibly closing H2 connection. It was used as a way to overcome the H2 issues with XA connection. > As the quickstart tests recovery it arbitrary throws an exception. This makes issue for H2 as it consider the connection as unfinished but if we close it it does not care and sets autocommit to true and let all the changes being immediately propagated to database. > That's what we don't want as we test recovery and we expect recovery to finish the in-doubt data. > The issue is only for H2 behaviour. "Normal" databases as PostgreSQL makes checks on unfinished transaction in jdbc driver and their decisions are based on it. > Nevertheless using reflection is not a good habit and it's a hacky. For quickstarts it should not be the case. There needs to be a way how to avoid it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3070) Quickstart for transaction driver should not use reflection

by Ondra Chaloupka (Jira)

Ondra Chaloupka created JBTM-3070: ------------------------------------- Summary: Quickstart for transaction driver should not use reflection Key: JBTM-3070 URL: https://issues.jboss.org/browse/JBTM-3070 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Currently the quickstart of transaction driver standalone uses reflection for forcibly closing H2 connection. It was used as a way to overcome the H2 issues with XA connection. As the quickstart tests recovery it arbitrary throws an exception. This makes issue for H2 as it consider the connection as unfinished but if we close it it does not care and sets autocommit to true and let all the changes being immediately propagated to database. That's what we don't want as we test recovery and we expect recovery to finish the in-doubt data. The issue is only for H2 behaviour. "Normal" databases as PostgreSQL makes checks on unfinished transaction in jdbc driver and their decisions are based on it. Nevertheless using reflection is not a good habit and it's a hacky. For quickstarts it should not be the case. There needs to be a way how to avoid it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3069) XTS over SSL Quickstart failed

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3069?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3069: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > XTS over SSL Quickstart failed > ------------------------------ > > Key: JBTM-3069 > URL: https://issues.jboss.org/browse/JBTM-3069 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing, XTS > Reporter: Amos Feng > Assignee: Ondra Chaloupka > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues October 2018