River
  1. River
  2. RIVER-39

visibility semantics in transaction spec incomplete

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: jtsk_1.1
    • Fix Version/s: None
    • Component/s: net_jini_core
    • Labels:
      None
    • Bugtraq ID:
      4512970

      Description

      Bugtraq ID 4512970

      TX.3.5 doesn't make clear what happens to visibility state when a top-level transaction commits. It also doesn't make clear that there can be conflicts between locks and visibility state (deletion in particular). Parallels to the statements made about the effect of conflicts on operations that attempt to acquire locks need to made about the effect of conflicts on operations that attempt to delete.

      The terminology is also somewhat confusing. There is a distinction between the created/deleted state of an object, which is inherited as subtransactions commit, and the visibility of an object to an arbitrary transaction, which is not inherited. Using the phrase "visibility state" and "creation/deletion visibility" for the former confuses it with the latter.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jim Hurley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development