Uploaded image for project: 'ModeShape'
  1. ModeShape
  2. MODE-2277

Improve performance of isCheckedOut

    XMLWordPrintable

Details

    Description

      hchiorean writes (initially in MODE-2276):

      In writing some more tests and looking at performance data while adding nodes, I found another potential significant bottleneck not only for adding nodes but also for setting properties: AbstractJcrNode#isCheckedOut (called both from #addNode and #setProperty). This is especially visible when running a deep hierarchy of nodes, where this method will load the entire hierarchy of parents for a child node, no matter how deep.

      Is there any way we can optimize this (e.g. store some sort of boolean flag each time we check out a node, so that we can easily compute the checked out status of a path. Or looking at the node types for mix:versionable) ?

      Attachments

        Issue Links

          causes

          Bug - A problem that impairs or prevents the functions of the product. MODE-2642 Node.isLocked() within a transaction returns false for a locked node

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved
          is related to

          Feature Request - Feature requests from customers and/or users MODE-2109 Support nodes with a very large number of unordered and uniquely-named children

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Bug - A problem that impairs or prevents the functions of the product. MODE-2271 Improve performance of getting path of node that is below a large ancestor

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Resolved

          Enhancement - An enhancement to or refactoring of existing functionality that is not configurable by an end user (typically a change made by an internal team that affects users) MODE-2266 Create simple scalability and performance tests

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Resolved

          Enhancement - An enhancement to or refactoring of existing functionality that is not configurable by an end user (typically a change made by an internal team that affects users) MODE-2276 Improve performance of adding node under parent

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              hchiorean Horia Chiorean (Inactive)
              rhauch Randall Hauch (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: