April 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2889) Include a vertx with STM quickstart

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2889?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2889: ----------------------------------- Summary: Include a vertx with STM quickstart (was: Include an vertx with STM quickstart) > Include a vertx with STM quickstart > ----------------------------------- > > Key: JBTM-2889 > URL: https://issues.jboss.org/browse/JBTM-2889 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, STM > Affects Versions: 5.5.24.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > It would be useful to include a quickstart that shows how to use STM with vertx -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2889) Include an vertx with STM quickstart

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2889: -------------------------------------- Summary: Include an vertx with STM quickstart Key: JBTM-2889 URL: https://issues.jboss.org/browse/JBTM-2889 Project: JBoss Transaction Manager Issue Type: Task Components: Demonstrator, STM Affects Versions: 5.5.24.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional Fix For: 5.next It would be useful to include a quickstart that shows how to use STM with vertx -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2888) NestedTopLevel transactions do not rollback state on exception

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2888?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2888: ----------------------------------- Attachment: NestedTopLevel2UnitTest.java > NestedTopLevel transactions do not rollback state on exception > -------------------------------------------------------------- > > Key: JBTM-2888 > URL: https://issues.jboss.org/browse/JBTM-2888 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.5.24.Final > Reporter: Michael Musgrove > Assignee: Mark Little > Attachments: NestedTopLevel2UnitTest.java > > > The attached file is a reproducer. Drop it into the STM tests directory and run to see the failure. > It creates two transactional objects A and B. B is further annotated with @NestedTopLevel. The test: > - starts a transaction A; > - calls a write method on A; > - then calls a write method on B which throws an exception; > - aborts or commits A (either outcome produces the error) > Since the container starts a top-level transaction for the call to the method on B I would expect it to abort it if the B method throws an exception. What I find is that it will always call commit. > This behaviour limits the usefulness of @NestedTopLevel when such methods are called inside an existing transaction since there is no mechanism for rolling back changes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2888) NestedTopLevel transactions do not rollback state on exception

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2888: -------------------------------------- Summary: NestedTopLevel transactions do not rollback state on exception Key: JBTM-2888 URL: https://issues.jboss.org/browse/JBTM-2888 Project: JBoss Transaction Manager Issue Type: Bug Components: STM Affects Versions: 5.5.24.Final Reporter: Michael Musgrove Assignee: Mark Little The attached file is a reproducer. Drop it into the STM tests directory and run to see the failure. It creates two transactional objects A and B. B is further annotated with @NestedTopLevel. The test: - starts a transaction A; - calls a write method on A; - then calls a write method on B which throws an exception; - aborts or commits A (either outcome produces the error) Since the container starts a top-level transaction for the call to the method on B I would expect it to abort it if the B method throws an exception. What I find is that it will always call commit. This behaviour limits the usefulness of @NestedTopLevel when such methods are called inside an existing transaction since there is no mechanism for rolling back changes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2887) No warnings if a field marked with @State is not a supported datatype

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2887?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2887: ---------------------------------------- Supported types are Boolean, Byte, Short, Integer, Long, Float, Double, Character, String and Transactional. LockManagerProxy#packObjectType() contains the definitive list. > No warnings if a field marked with @State is not a supported datatype > --------------------------------------------------------------------- > > Key: JBTM-2887 > URL: https://issues.jboss.org/browse/JBTM-2887 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.5.24.Final > Reporter: Michael Musgrove > Assignee: Mark Little > > If a field annotated with @State (such as a map) is not one of the supported datatypes then any attempt to obtain an STM lock will fail with LockResult.REFUSED. > It would be useful if a warning is logged to indicate why lock acquisition is refused to prompt the developer to override the save_state and restore_state methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2887) No warnings if a field marked with @State is not a supported datatype

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2887: -------------------------------------- Summary: No warnings if a field marked with @State is not a supported datatype Key: JBTM-2887 URL: https://issues.jboss.org/browse/JBTM-2887 Project: JBoss Transaction Manager Issue Type: Bug Components: STM Affects Versions: 5.5.24.Final Reporter: Michael Musgrove Assignee: Mark Little If a field annotated with @State (such as a map) is not one of the supported datatypes then any attempt to obtain an STM lock will fail with LockResult.REFUSED. It would be useful if a warning is logged to indicate why lock acquisition is refused to prompt the developer to override the save_state and restore_state methods. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-1732: ---------------------------------------- This issue also applies to in memory stores (ie STM objects created using Container.TYPE.RECOVERABLE). > Durable STM instances require explicit sync to save state > --------------------------------------------------------- > > Key: JBTM-1732 > URL: https://issues.jboss.org/browse/JBTM-1732 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: STM > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Mark Little > Priority: Optional > > As with TXOJ, a persistent STM object isn't written to disk until a write lock is acquired on it within the scope of a transaction. Consider automating this at creation time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2885) Orphan detection may attempt to rollback orphan if resource fails to return values

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2885?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2885: -------------------------------- Description: If the XAR returns a Xid from recover(FIRST_PASS) to XARM but then goes offline for a cycle we may attempt to rollback the Xid thinking it is stale. If the XAR returns an XAE at that point we should clear the _xidScans so we pick it up next time. However, there is a filter that checks for transaction state (JTATransactionLogXAResourceOrphanFilter) which would detect a transaction log and ignore this Xid so adding this protection would only be considered belt-and-braces. was: If the XAR returns a Xid from recover(FIRST_PASS) to XARM but then goes offline for a cycle we may attempt to rollback the Xid thinking it is stale. If the XAR returns an XAE at that point we should clear the _xidScans so we pick it up next time. However, there is a filter that checks for transaction state which would detect a transaction log and ignore this Xid so adding this protection would only be considered belt-and-braces. > Orphan detection may attempt to rollback orphan if resource fails to return values > ---------------------------------------------------------------------------------- > > Key: JBTM-2885 > URL: https://issues.jboss.org/browse/JBTM-2885 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Optional > Fix For: 5.next > > > If the XAR returns a Xid from recover(FIRST_PASS) to XARM but then goes offline for a cycle we may attempt to rollback the Xid thinking it is stale. If the XAR returns an XAE at that point we should clear the _xidScans so we pick it up next time. > However, there is a filter that checks for transaction state (JTATransactionLogXAResourceOrphanFilter) which would detect a transaction log and ignore this Xid so adding this protection would only be considered belt-and-braces. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2885) Orphan detection may attempt to rollback orphan if resource fails to return values

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2885?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2885: -------------------------------- Description: If the XAR returns a Xid from recover(FIRST_PASS) to XARM but then goes offline for a cycle we may attempt to rollback the Xid thinking it is stale. If the XAR returns an XAE at that point we should clear the _xidScans so we pick it up next time. However, there is a filter that checks for transaction state which would detect a transaction log and ignore this Xid so adding this protection would only be considered belt-and-braces. was: If the XAR returns a Xid from recover(FIRST_PASS) to XARM but then goes offline we may attempt to rollback the Xid thinking it is stale. If the XAR returns an XAE at that point we should clear the _xidScans so we pick it up next time. However, the filter that checks for transaction state should detect a transaction log and ignore this Xid anyway. > Orphan detection may attempt to rollback orphan if resource fails to return values > ---------------------------------------------------------------------------------- > > Key: JBTM-2885 > URL: https://issues.jboss.org/browse/JBTM-2885 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Optional > Fix For: 5.next > > > If the XAR returns a Xid from recover(FIRST_PASS) to XARM but then goes offline for a cycle we may attempt to rollback the Xid thinking it is stale. If the XAR returns an XAE at that point we should clear the _xidScans so we pick it up next time. > However, there is a filter that checks for transaction state which would detect a transaction log and ignore this Xid so adding this protection would only be considered belt-and-braces. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2885) Orphan detection may attempt to rollback orphan if resource fails to return values

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2885?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2885: -------------------------------- Summary: Orphan detection may attempt to rollback orphan if resource fails to return values (was: Orphan detection may attempt to rollback XID even if XAR did not report Xid due to failure) > Orphan detection may attempt to rollback orphan if resource fails to return values > ---------------------------------------------------------------------------------- > > Key: JBTM-2885 > URL: https://issues.jboss.org/browse/JBTM-2885 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Optional > Fix For: 5.next > > > If the XAR returns a Xid from recover(FIRST_PASS) to XARM but then goes offline we may attempt to rollback the Xid thinking it is stale. If the XAR returns an XAE at that point we should clear the _xidScans so we pick it up next time. > However, the filter that checks for transaction state should detect a transaction log and ignore this Xid anyway. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 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 April 2017