OpenJPA
  1. OpenJPA
  2. OPENJPA-2167

Misc changes to improve flush() path performance

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.1, 2.3.0
    • Fix Version/s: 2.2.1, 2.3.0
    • Component/s: kernel, performance
    • Labels:
      None

      Description

      In StateManagerImpl.proxyFields(), we blindly replace the proxy fields as long as they loaded. We can be slightly more efficient if we also verify that the field has been dirtied before doing the replacement.

      The original intent of this JIRA was to just resolve the issue with proxyFields. But, as I continue to dive into this flush() path, there are a few other minor updates that need to be done (reference the comments on this JIRA).

        Activity

        Hide
        Rick Curtis added a comment -

        Committed changes to trunk and 2.2.x.

        Show
        Rick Curtis added a comment - Committed changes to trunk and 2.2.x.
        Hide
        Kevin Sutter added a comment -

        Using a HashSet for the cancel-able prepared statements was overkill. In most cases, this would only be a single entry. So, I'm going to change this to a List with an initial size of 1. We can then test whether each Statement needs to be canceled instead of relying on the Set behavior.

        Show
        Kevin Sutter added a comment - Using a HashSet for the cancel-able prepared statements was overkill. In most cases, this would only be a single entry. So, I'm going to change this to a List with an initial size of 1. We can then test whether each Statement needs to be canceled instead of relying on the Set behavior.
        Hide
        Kevin Sutter added a comment -

        I also found where OpenJPA was not allowing the use of the "none" value for openjpa.AutoDetach – although it's documented. When using JPA, we're currently hard-coded the value of AutoDetach to "Close" and "Rollback", and "None" is not allowed. But, if you are doing some debugging and looking to allow for the "none" setting, the code didn't have it defined. So, I am adding it back in to match the documentation.

        Show
        Kevin Sutter added a comment - I also found where OpenJPA was not allowing the use of the "none" value for openjpa.AutoDetach – although it's documented. When using JPA, we're currently hard-coded the value of AutoDetach to "Close" and "Rollback", and "None" is not allowed. But, if you are doing some debugging and looking to allow for the "none" setting, the code didn't have it defined. So, I am adding it back in to match the documentation.
        Hide
        Kevin Sutter added a comment -

        As I was working this Issue I also found where we could check for an empty TransactionEventManager to avoid a few layers in the callstack.

        Show
        Kevin Sutter added a comment - As I was working this Issue I also found where we could check for an empty TransactionEventManager to avoid a few layers in the callstack.

          People

          • Assignee:
            Kevin Sutter
            Reporter:
            Kevin Sutter
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development