December 2009 - dna-issues - Jboss List Archives

[JBoss JIRA] Created: (DNA-582) The connector.execute(...) method is not 'all-or-nothing'

by Randall Hauch (JIRA)

The connector.execute(...) method is not 'all-or-nothing' --------------------------------------------------------- Key: DNA-582 URL: https://jira.jboss.org/jira/browse/DNA-582 Project: DNA Issue Type: Bug Components: Connectors, Graph Reporter: Randall Hauch Priority: Blocker Fix For: 1.0 The RepositoryConnector.execute(ExecutionContext,Request) method does not have all-or-nothing behavior. That is, if the request is a CompositeRequest with multiple requests to change the content, and some of those change requests result in errors, the execution should 'rollback' the changes and return the content to the state before the method was called. In other words, either all of the requests are fulfilled, or none of them are. None of the writable connectors work this way, and they all need to be corrected. Also, this behavior needs to be documented in the connector API. Finally, we need to make sure that the JCR session's transient state is unchanged if a save() call results in an error (the connector's state should rollback, but the session's state should remain, per Section 7.1.1.6-7.1.1.7 of JCR 1.0.1). -- 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

14 years, 5 months

1
4
0 / 0

[JBoss JIRA] Created: (DNA-588) The connectors should release all resources before notifying observer of events

by Randall Hauch (JIRA)

The connectors should release all resources before notifying observer of events ------------------------------------------------------------------------------- Key: DNA-588 URL: https://jira.jboss.org/jira/browse/DNA-588 Project: DNA Issue Type: Bug Components: Connectors, Graph Affects Versions: 0.7 Reporter: Randall Hauch Fix For: 1.0 Right now, most connectors are firing off the changes to the Observer before the resources acquired by the connector are released, meaning that the Observer cannot use the source within the same thread. This prevents writing Observers that operate fully before the 'execute(...)' method returns, and requires that any Observer that might need access to the source needs to do its work asynchronously. By notifying the Observer _after_ the resources are released but before 'execute(...)' returns, Observers could call back to the source (really through a different connection or at least through a different 'execute(...)' call) to access content. This means that Observers could be written to work synchronously while still access the (committed) content. -- 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

14 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (DNA-585) The JPA connector.execute(...) method is not 'all-or-nothing'

by Randall Hauch (JIRA)

The JPA connector.execute(...) method is not 'all-or-nothing' ------------------------------------------------------------- Key: DNA-585 URL: https://jira.jboss.org/jira/browse/DNA-585 Project: DNA Issue Type: Sub-task Components: Connectors Affects Versions: 0.7 Reporter: Randall Hauch Priority: Blocker Fix For: 1.0 We should be able to just commit or rollback, but we just need to do this at the appropriate time. -- 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

14 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (DNA-590) The FederatedConnector connector.execute(...) method is not 'all-or-nothing'

by Randall Hauch (JIRA)

The FederatedConnector connector.execute(...) method is not 'all-or-nothing' ---------------------------------------------------------------------------- Key: DNA-590 URL: https://jira.jboss.org/jira/browse/DNA-590 Project: DNA Issue Type: Sub-task Components: Connectors, Federation Affects Versions: 0.7 Reporter: Randall Hauch Fix For: 1.0 The federation connector needs to ensure that either changes are made to all connectors or changes are made to none. This is going to be a challenge if multiple sources are involved in a transaction (without resorting to a transaction manager and XA). -- 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

14 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-587) The FileSystem connector.execute(...) method is not 'all-or-nothing'

by Randall Hauch (JIRA)

The FileSystem connector.execute(...) method is not 'all-or-nothing' -------------------------------------------------------------------- Key: DNA-587 URL: https://jira.jboss.org/jira/browse/DNA-587 Project: DNA Issue Type: Sub-task Components: Connectors Affects Versions: 0.7 Reporter: Randall Hauch Priority: Blocker Fix For: 1.0 Making this happen might be a bit tough. We might have to copy any changed files and changed/removed directories into a temporary area, and then move them back upon rollback. -- 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

14 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-586) The JBoss Cache connector.execute(...) method is not 'all-or-nothing'

by Randall Hauch (JIRA)

The JBoss Cache connector.execute(...) method is not 'all-or-nothing' --------------------------------------------------------------------- Key: DNA-586 URL: https://jira.jboss.org/jira/browse/DNA-586 Project: DNA Issue Type: Sub-task Components: Connectors Affects Versions: 0.7 Reporter: Randall Hauch Priority: Blocker Fix For: 1.0 We should be able to rely upon the transactional semantics of JBoss Cache. -- 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

14 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-584) The Infinispan connector.execute(...) method is not 'all-or-nothing'

by Randall Hauch (JIRA)

The Infinispan connector.execute(...) method is not 'all-or-nothing' -------------------------------------------------------------------- Key: DNA-584 URL: https://jira.jboss.org/jira/browse/DNA-584 Project: DNA Issue Type: Sub-task Components: Connectors Affects Versions: 0.7 Reporter: Randall Hauch Priority: Blocker Fix For: 1.0 We should be able to rely upon the transactional semantics of Infinispan. -- 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

14 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-581) Alter logging to use categories and message codes

by Randall Hauch (JIRA)

Alter logging to use categories and message codes -------------------------------------------------- Key: DNA-581 URL: https://jira.jboss.org/jira/browse/DNA-581 Project: DNA Issue Type: Task Components: Common Affects Versions: 0.7 Reporter: Randall Hauch Fix For: 1.1 Our logging facility should use message codes that can be used to cross-reference more information about the message and possible actions to alter the behavior. The logging should also use categories rather than just using class names. Ideally this can be done such that the only changes are to the logging class and the I18n library, and that all other code remains untouched. (Though we'll have to record for each subproject the message codes in a file so they're durable and documented.) -- 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

14 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (DNA-445) Formally Delineate the Public API

by Brian Carothers (JIRA)

Formally Delineate the Public API --------------------------------- Key: DNA-445 URL: https://jira.jboss.org/jira/browse/DNA-445 Project: DNA Issue Type: Feature Request Components: API Affects Versions: 0.4 Reporter: Brian Carothers DNA has a fairly large number of classes, not all of which are intended to be stable. Although some examples and documentation "best practices" for utilizing the API are provided, there is no explicit contract in the API that indicates which portions of the API are expected to remain stable and supported over time. A comparable discussion was occurring on the jboss-development mailing list (https://lists.jboss.org/mailman/listinfo/jboss-development) Vol. 36 Issue 8 et al. It appears that Eclipse uses annotations to provide this information. These annotations (http://www.opends.org/promoted-builds/2.0.0-RC1/javadoc/org/opends/server... and http://www.eclipse.org/pde/pde-api-tools/) were tossed around in the discussion. -- 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

14 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (DNA-579) JcrObservationManagerTest Should Check To See If Listeners Receive Too Many Events

by Dan Florian (JIRA)

JcrObservationManagerTest Should Check To See If Listeners Receive Too Many Events ---------------------------------------------------------------------------------- Key: DNA-579 URL: https://jira.jboss.org/jira/browse/DNA-579 Project: DNA Issue Type: Bug Components: JCR Affects Versions: 0.7 Reporter: Dan Florian Assignee: Dan Florian Fix For: 0.7 The JcrObservationManagerTest is using a CountDownLatch to determine if the correct number of events are received by a JCR event listener. Once the correct number of events are received the test listener "quits" listening and the test passes (assuming the received events were the correct ones). What the test does not check is if too many events could've been broadcast to a listener (i.e., events that the listener has not been registered to receive). -- 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

14 years, 5 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-issues December 2009