Directory ApacheDS
  1. Directory ApacheDS
  2. DIRSERVER-849

Lacking atomicity for modify operations on schema subentry

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.0, 1.5.1
    • Fix Version/s: 2.0.0-M1
    • Component/s: schema
    • Labels:
      None

      Description

      Sometimes a modify operation may add or remove multiple schema entities. If one is bad yet others are not the modification for the bad entity is rejected while others are not. This failure of one entity should cause the entire operation to rollback to preserve atomicity of the modify operation on the schema subentry.

        Activity

        Hide
        Ersin Er added a comment -

        Is this a problem related to Subentry subsystem in general, or only related to Schema Subentries?

        Show
        Ersin Er added a comment - Is this a problem related to Subentry subsystem in general, or only related to Schema Subentries?
        Hide
        Alex Karasulu added a comment -

        Ersin you're intuition is right - I was in fact referring specifically to the schema subentries. I have edited the subject of the issue and delayed this for 1.5.2.

        Show
        Alex Karasulu added a comment - Ersin you're intuition is right - I was in fact referring specifically to the schema subentries. I have edited the subject of the issue and delayed this for 1.5.2.
        Hide
        Emmanuel Lecharny added a comment -

        Status ?

        Show
        Emmanuel Lecharny added a comment - Status ?
        Hide
        Emmanuel Lecharny added a comment -

        Postponed to 2.0.0-RC1

        Show
        Emmanuel Lecharny added a comment - Postponed to 2.0.0-RC1
        Hide
        Emmanuel Lecharny added a comment -

        The subschemasubentry management has been completely reviewed last year.

        The mentionned problem should not occur anymore, as the way we now handling schema modification is :

        • clone the entire schema
        • apply the modifications
        • check if the cloned schema is consistent
        • if not, ditch the cloned schema, and keep the previous one, then produce an error message
        • otherwise swap the old schema out and replace it with the new schema.
        Show
        Emmanuel Lecharny added a comment - The subschemasubentry management has been completely reviewed last year. The mentionned problem should not occur anymore, as the way we now handling schema modification is : clone the entire schema apply the modifications check if the cloned schema is consistent if not, ditch the cloned schema, and keep the previous one, then produce an error message otherwise swap the old schema out and replace it with the new schema.

          People

          • Assignee:
            Unassigned
            Reporter:
            Alex Karasulu
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development