September 2010 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-781) Document configuration fo XTS via jboss-beans.xml or xts-properties.xml

by Andrew Dinn (JIRA)

Document configuration fo XTS via jboss-beans.xml or xts-properties.xml ----------------------------------------------------------------------- Key: JBTM-781 URL: https://jira.jboss.org/browse/JBTM-781 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation, XTS Affects Versions: 4.12.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.13.0 New bean injection/property manager config needs to be documented -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-794) TransactionReaper may execute continuously

by Kevin Conner (JIRA)

TransactionReaper may execute continuously ------------------------------------------ Key: JBTM-794 URL: https://jira.jboss.org/browse/JBTM-794 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.6.1.CP07 Reporter: Kevin Conner JBossTS TransactionReaper contains a bug which results in the reaper executing continuously within dynamic mode, rather than pausing between runs. The ReaperThread calls the TransactionReaper.checkingPeriod() method to determine how long it should pause before it can invoke the TransactionReaper.check() method, however there exists a circumstance where the checkingPeriod() will return a negative period for a sustained time, resulting in the thread executing continuously. This occurs when the check() method is invoked while there are existing transactions in the ReaperElementManager. The check and checkingPeriod methods use the nextDynamicCheckTime variable to store the absolute time at which the next invocation of check should occur, checkingPeriod returns the difference between that time and the current. When the check method is executed after nextDynamicCheckTime has occurred, the method retrieves the first ReaperElement from the ReaperElementManager. The processing continues as follows - if no reaperElement present, reset nextDynamicCheckTime to Long.MAX_VALUE - if present and expired (reaperElement.getAbsoluteTimeout() <= now) then the element is processed - if present and not expired (reaperElement.getAbsoluteTimeout() > now) then do nothing. It is the last behaviour which is incorrect as the nextDynamicCheckTime still refers to the previous absolute timeout, i.e. < now, resulting in all calls to checkinPeriod() returning a negative value. This will only be halted if one of the other conditions is true, i.e. the ReaperElementManager is empty or the head element must be processed by this thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-787) provide bean based configuration, part 4

by Jonathan Halliday (JIRA)

provide bean based configuration, part 4 ---------------------------------------- Key: JBTM-787 URL: https://jira.jboss.org/browse/JBTM-787 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Configuration Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.13.0 The *EnvironmentBean class instances are currently singletons. This causes problems where we wish to have more than one instance of e.g. an ObjectStore with distinct configuration. Change the BeanPopulator and associated config file property naming convention such that we can have multiple instances of a given *Bean type. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBTM-788) refactor ObjectStore init/config

by Jonathan Halliday (JIRA)

refactor ObjectStore init/config -------------------------------- Key: JBTM-788 URL: https://jira.jboss.org/browse/JBTM-788 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Configuration, Transaction Core Affects Versions: 4.12.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.13.0 Until now ObjectStores have been configured using what are essentially global variables, most recently in the form of properties on a singleton instance of ObjectStoreEnvironmentBean. This causes a number of problems, including the inability to cleanly configure multiple stores with different settings and the need to add implementation specific properties to the bean even if only a small subset of implementations need them. To address this the model should be changed such that: - store implementations take a bean as a constructor arg. StoreManager should be pretty much the only point of instantiation in the production code (unit tests are a law unto themselves) and takes care of supplying an appropriate bean instance via BeanPopulator and the 'multiple bean instances' change in JBTM-787. - the type of the *EnvironmentBean instance should be determined by reflection on the instance constructor or such, allowing for beans to have implementation specific properties only. For example, a Dir makes no sense for the JDBC store and contrawise connection params don't apply to the filesystem based stores. Note that as a side effect of these and earlier changes to the log format, the 'serialization' of objectstores into the log is no longer used. To reinstate it we'd need more than the original 'ObjectStoreType' stuff - a store instance is now effectively identified by impl class and config values, so we'd need to make the beans serializable too. This is a departure from the C++ version towards something more Java/DI centric. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-750) replace CLF with jboss-logging

by Jonathan Halliday (JIRA)

replace CLF with jboss-logging ------------------------------ Key: JBTM-750 URL: https://jira.jboss.org/browse/JBTM-750 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Common Affects Versions: 4.11.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.12.0 jboss-logging provides an abstraction over 3rd party logging frameworks and i18n, which is pretty much what CLF does. No point in maintaining both and jboss-logging fits the TAG-2 and TAG-3 requirements better. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-728) Add remote tests to emma coverage

by Mark Little (JIRA)

Add remote tests to emma coverage --------------------------------- Key: JBTM-728 URL: https://jira.jboss.org/jira/browse/JBTM-728 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS, Testing Reporter: Mark Little Assignee: Jonathan Halliday Fix For: 4.11.0 The remote tests in JTS were developed to be run manually with specific interceptor options mentioned on the command line. Although they are now junit tests it doesn't seem that all of the options are being used, or perhaps the server side component isn't being covered by emma, because interceptor classes that should be called aren't mentioned in the report. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
6
0 / 0

[JBoss JIRA] Updated: (JBTM-44) Transaction bridging

by Jonathan Halliday (JIRA)

[ https://jira.jboss.org/browse/JBTM-44?page=com.atlassian.jira.plugin.syst... ] Jonathan Halliday updated JBTM-44: ---------------------------------- Fix Version/s: 4.14.0 (was: 4.13.0) > Transaction bridging > -------------------- > > Key: JBTM-44 > URL: https://jira.jboss.org/browse/JBTM-44 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTA, JTS, XTS > Reporter: Mark Little > Assignee: Jonathan Halliday > Priority: Critical > Fix For: 4.14.0 > > Attachments: jbossxts-bridge.zip > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-790) XTS demo should fully exercise latest recovery API

by Andrew Dinn (JIRA)

XTS demo should fully exercise latest recovery API -------------------------------------------------- Key: JBTM-790 URL: https://jira.jboss.org/browse/JBTM-790 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.12.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.13.0 The XTS demo does not currently fully exercise the recovery API because it is faking modifying and persisting changes of web service state via a local transactional resource. This means it does not need to link the prepare and commit cycle for the local state to the progress of the encompassing AT or BA web service transaction. In particular the new API methods introduced as part of JBTM-786 are not being exercised. The demo should be updated to employ a simple local transactional resource and to drive this resource correctly using the new API. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBTM-712) Improve test coverage for jta

by Mark Little (JIRA)

Improve test coverage for jta ----------------------------- Key: JBTM-712 URL: https://jira.jboss.org/jira/browse/JBTM-712 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA, Testing Reporter: Mark Little Assignee: Mark Little Fix For: 4.11.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (JBTM-699) Command line interface to modifying transaction log during recovery

by Mark Little (JIRA)

Command line interface to modifying transaction log during recovery ------------------------------------------------------------------- Key: JBTM-699 URL: https://jira.jboss.org/jira/browse/JBTM-699 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Recovery, Tooling, Transaction Core Reporter: Mark Little Assignee: Mark Little Fix For: 4.10.0 Similar to the OS browser. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues September 2010