jpa-spec
  1. jpa-spec
  2. JPA_SPEC-37

Improve JPA compliance statement in 3.5.2 for injected resources

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:
      None

      Description

      Copied from https://issues.jboss.org/browse/CDI-144

      JPA spec 3.5.2 states: "In general, the lifecycle method of a portable application should not invoke EntityManager or Query operations, access other entity instances, or modify relationships within the same persistence context.[45] A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked."

      Since I have been running into this issue lately: Shouldn't we add a note somewhere that injected (CDI) resources require special attention regarding JPA compliance? And because of that firing CDI events from JPA entity listeners is particularly dangerous?

      In my case I tried to implement global available created/updated/deleted entity events which turned out to be a bad idea if implemented on EntityListener level.

        Activity

        Hide
        ldemichiel added a comment -

        Please explain more concretely what you mean by "dangerous" or the advice that you propose the JPA spec should add.

        Show
        ldemichiel added a comment - Please explain more concretely what you mean by "dangerous" or the advice that you propose the JPA spec should add.
        Hide
        frenchc added a comment - - edited

        CDI injection - or better injected resources in general - will make it easy to violate the above rule. E.g. i simply don't know wether the current implementation of an injected service will issue JPA write or query operations. CDI events can increase the risk, since I don't know who is listing.

        Image you change your programming model to a more event oriented programming model. Instead of implementing the use case "Add new Customer (and send welcome e-mail and create a new account for this customer)" in one single place i could go ahead and implement the primary use case "Add new customer" and fire an @Created Customer event. All secondary functionality (send welcome e-mail, create new account) will be implemented in event observers. But firing those events from JPA entity listeners will increase the risk of creating non portable applications.

        I have to admit that I have no idea how to express the risk in a spec. How about.

        "In general, the lifecycle method and its dependencies should not invoke EntityManager or Query operations, access other entity instances, or modify relationships within the same persistence context in order to remain portable. Dependencies could be any injected dependency - as defined in 3.5.1 - or arbitrary CDI event consumers. A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked."

        Show
        frenchc added a comment - - edited CDI injection - or better injected resources in general - will make it easy to violate the above rule. E.g. i simply don't know wether the current implementation of an injected service will issue JPA write or query operations. CDI events can increase the risk, since I don't know who is listing. Image you change your programming model to a more event oriented programming model. Instead of implementing the use case "Add new Customer (and send welcome e-mail and create a new account for this customer)" in one single place i could go ahead and implement the primary use case "Add new customer" and fire an @Created Customer event. All secondary functionality (send welcome e-mail, create new account) will be implemented in event observers. But firing those events from JPA entity listeners will increase the risk of creating non portable applications. I have to admit that I have no idea how to express the risk in a spec. How about. "In general, the lifecycle method and its dependencies should not invoke EntityManager or Query operations, access other entity instances, or modify relationships within the same persistence context in order to remain portable. Dependencies could be any injected dependency - as defined in 3.5.1 - or arbitrary CDI event consumers. A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked."
        Hide
        ldemichiel added a comment -

        That's a helpful clarification - thanks. I will add something along those lines as a cautionary note to the spec.

        Show
        ldemichiel added a comment - That's a helpful clarification - thanks. I will add something along those lines as a cautionary note to the spec.
        Hide
        ldemichiel added a comment -

        I've now added a cautionary footnote that this concern applies also to the operations of objects that may have been injected into entity listeners.

        Show
        ldemichiel added a comment - I've now added a cautionary footnote that this concern applies also to the operations of objects that may have been injected into entity listeners.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: