OpenJPA
  1. OpenJPA
  2. OPENJPA-305

Dynamic configuration of EntityManagerFactory

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1.0, 1.2.0
    • Component/s: None
    • Labels:
      None

      Description

      OpenJPA configures EntityManagerFactory at creation time via an instance of Configuartion object. Once EntityManagerFactory is created and a EntityManager is issued from it – the Configuration is frozen by design. That is no further changes to Configuration is allowed as long as EntityManagerFactory lives.

      For certain configuration properties, it is desirable to change them during the lifetime of a EntityManagerFactory.
      This issue is raised to initiate a discussion on such a feature, the possibility and limitations of dynamic update and track the impact of such a change as frozen Configuration is an important assumption.

        Issue Links

          Activity

          Hide
          Pinaki Poddar added a comment -

          Dynamic (i.e. while EntityManagerFactory is alive) change of Configuration will impact the pooling of BrokerFactory (which is the core implementation of which EntityManagerFactory is a facade).

          The pool maintains a Map of poolKey to BrokerFactory. A poolKey is effectively the Configuration expressed as a Property. So dynamically changing configuration properties must take into account the integrity of this pool which is till now based on the assumption of constancy of Configuration.

          Possibility of using IdentityHashMap and use the Configuration instance (not its Property values) as key:
          This is most likely not going to work. The idea of freezing the config at the first place (perhaps) originated because callers who supply new copies of Configuration (that are same by value but not by identity) expect to get the same Factory.

          Show
          Pinaki Poddar added a comment - Dynamic (i.e. while EntityManagerFactory is alive) change of Configuration will impact the pooling of BrokerFactory (which is the core implementation of which EntityManagerFactory is a facade). The pool maintains a Map of poolKey to BrokerFactory. A poolKey is effectively the Configuration expressed as a Property. So dynamically changing configuration properties must take into account the integrity of this pool which is till now based on the assumption of constancy of Configuration. Possibility of using IdentityHashMap and use the Configuration instance (not its Property values) as key: This is most likely not going to work. The idea of freezing the config at the first place (perhaps) originated because callers who supply new copies of Configuration (that are same by value but not by identity) expect to get the same Factory.
          Hide
          Patrick Linskey added a comment -

          I think that the best approach is to make the key computation be based on the original values. That way, any lookups for a configuration with a given set of original values will route to the same (possibly-mutated) new values.

          Show
          Patrick Linskey added a comment - I think that the best approach is to make the key computation be based on the original values. That way, any lookups for a configuration with a given set of original values will route to the same (possibly-mutated) new values.
          Hide
          Craig L Russell added a comment -

          I agree with Patrick.

          The intent of making the EMF not configurable after the first getEM is just so that you can find an EMF based on the user-defined values.

          If you ask for an EMF that has a default property, and that property has changed, then you cannot get the behavior you expect.

          Show
          Craig L Russell added a comment - I agree with Patrick. The intent of making the EMF not configurable after the first getEM is just so that you can find an EMF based on the user-defined values. If you ask for an EMF that has a default property, and that property has changed, then you cannot get the behavior you expect.
          Hide
          Pinaki Poddar added a comment -

          This is a proposed patch that makes few significant changes in Value-Configuration part to support dynamic update of Configuration. Hence this is a patch for your comment/review.

          1. The intents are
          a) certain Values can be marked dynamic. This allows them to be modified even after the configuration is frozen i.e. EntityManagerFactory has issued its first EntityManager.

          b) because EntityManagerFactories are cached based on the keys of their configuration, the hashCode of the configuration must not be changed when a dynamic value V changes from x1 to x2.
          For example, for Configuration A, one of it's value V(A) is originally set to x1. Later it was modified to x2.
          A.hashCode() should remain the same before and after the modification if V is dynamic.

          c) Equality: Two Configuration A and B had originally V(A)=x and V(B)=y where V is dynamic.
          Initially x!=y. That implies A not equals B.
          Now V(B) is set to x. Does A now equals B?
          The intended answer is no.

          2. What needed to support (1c) is notion of 'originalValue' for dynamic properties. This patch implements by declaring a new String field in Value.class, also logic of setting this 'originalValue' in setString() and setObject() methods.

          3. The 'originalValue' notion is used for changed behavior of Value.equals() and Value.hashCode() methods.

          4. ConfigurationImpl used to compute its hashCode() and equals() by first converting itself into a Properties object. I do not why. That is the main reason this is submitted as a patch for everyone's comment/review.
          This patch makes a conceptual change. Now ConfigurationImpl computes its hashCode() and equals() based on its Values – who in turn evaluates their own hashCode() and equals() that varies based on their dynamic nature.

          Show
          Pinaki Poddar added a comment - This is a proposed patch that makes few significant changes in Value-Configuration part to support dynamic update of Configuration. Hence this is a patch for your comment/review. 1. The intents are a) certain Values can be marked dynamic. This allows them to be modified even after the configuration is frozen i.e. EntityManagerFactory has issued its first EntityManager. b) because EntityManagerFactories are cached based on the keys of their configuration, the hashCode of the configuration must not be changed when a dynamic value V changes from x1 to x2. For example, for Configuration A, one of it's value V(A) is originally set to x1. Later it was modified to x2. A.hashCode() should remain the same before and after the modification if V is dynamic. c) Equality: Two Configuration A and B had originally V(A)=x and V(B)=y where V is dynamic. Initially x!=y. That implies A not equals B. Now V(B) is set to x. Does A now equals B? The intended answer is no. 2. What needed to support (1c) is notion of 'originalValue' for dynamic properties. This patch implements by declaring a new String field in Value.class, also logic of setting this 'originalValue' in setString() and setObject() methods. 3. The 'originalValue' notion is used for changed behavior of Value.equals() and Value.hashCode() methods. 4. ConfigurationImpl used to compute its hashCode() and equals() by first converting itself into a Properties object. I do not why. That is the main reason this is submitted as a patch for everyone's comment/review. This patch makes a conceptual change. Now ConfigurationImpl computes its hashCode() and equals() based on its Values – who in turn evaluates their own hashCode() and equals() that varies based on their dynamic nature.
          Hide
          Patrick Linskey added a comment -

          Generally, it looks good. Some comments:

          I don't understand why we do the isDynamic() check in equals() and hashCode(), though; shouldn't getOriginalValue() always be correct?

          Also, it looks like there's a synchronization issue at hand – based on my reading, dynamic sets must occur in a synchronized manner, or the behavior is non-deterministic. That is OK (I don't think that we necessarily want to add synchronization on accesses), but should be well-documented.

          Show
          Patrick Linskey added a comment - Generally, it looks good. Some comments: I don't understand why we do the isDynamic() check in equals() and hashCode(), though; shouldn't getOriginalValue() always be correct? Also, it looks like there's a synchronization issue at hand – based on my reading, dynamic sets must occur in a synchronized manner, or the behavior is non-deterministic. That is OK (I don't think that we necessarily want to add synchronization on accesses), but should be well-documented.

            People

            • Assignee:
              Pinaki Poddar
              Reporter:
              Pinaki Poddar
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development