Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      Currently a JPA provider cannot guarantee that Entities are serializable since it is always possible that the entity is pessimistically locked (select for update).

      The other problem is that JPA entities (per spec) loose all the state of lazy loaded fields and their dirty tracking information on serialisation. The result is that you basically cannot use them for any web application. Even if most EE6 samples use entities directly in their backing beans this does not work in practice (if you do not use non-spec conform magic switches) if clustering kicks in or you use e.g. the JSF ViewMap to store your entities.

      The JPA spec currently states that you can either use lazy loading or serialisation. But this is impracticable. Not being Serializable means that you cannot use Entities in a webapp. Not having LazyLoading means that you will end up with 'database spaghetti' (pulling one entity and materializing half the database).

      A possible solution:

      step A:

      /**
       * This one only allows optimistic operations and will throw an Exception on pessimistic ones.
       * It can be created via EntityManagerFactory#createOptimisticEntityManager()
       */
      public interface OptimisticEntityManager extends EntityManager, Serializable {}
      

      step B:

      force that each @Entity produced via this OptimisticEntityManager must explicitly declare the following fields:

      • @Id and @Version. Otherwise you cannot do optimistic locking properly after serialisation.
      • a state field [1] to serialize all information needed to track dirty fields and lazy loading information even after serialisation.

      [1] I'm not yet sure how to implement this best. OpenJPA and EclipseLink already store all the state in the enriched/enhanced/weaved entity. The problem is just that they need to be switched to a mode where they do not only serialize the native entity but also all additionally needed info as well.
      Since Hibernate stores all this information in the EntityManager (and not in the Entity), we need to spare some field in the Entity which will get filled when the entity gets detached.

      One way would be to introduce a new field of type javax.persistence.State which must always be available in Serializable entities used by an OptimisticEntityManager. Of course this field never gets persisted to the db.

      Any other ideas and spec clarifications (if I misunderstood something) is highly welcome!

        Activity

        Hide
        mkeith added a comment -

        We have actually spent a great of time discussing variants of this problem since the first release of JPA, and there are a few possible solutions to the problem, but because of differing vendor opinions, implementations, and philosophies we have not yet reached a satisfactory conclusion. Unfortunately it is doubtful we will be able to do so in this release, either.

        Show
        mkeith added a comment - We have actually spent a great of time discussing variants of this problem since the first release of JPA, and there are a few possible solutions to the problem, but because of differing vendor opinions, implementations, and philosophies we have not yet reached a satisfactory conclusion. Unfortunately it is doubtful we will be able to do so in this release, either.
        Hide
        Mark Struberg added a comment -

        Hi Mike!

        Thanks for the honest answer. As I am EG member on other JSR myself, I certainly know those 'games'. This special issue has indeed a long history. I've seen EJB bug reports from 2005 (or even older?) which are originated in this very problem. And they all got bulk-updated and set to closed WITHOUT solving the underlying problem.

        But all this doesn't change the fact that this is still broken and users don't care about political games behind the scene. This is really one of the reasons why user turn away from JPA and use SpringData, iBatis and eBean instead.

        Currently the only way you can work with JPA in big projects is the old EJB transaction pattern where all entities get detached after the service invocation and NOT get used anymore in JSF pages or even JSF backing beans. But exactly that is what most EE6 samples currently showcase - despite being broken. This also renders JSR-303 mostly useless. Really, the only way to use JPA in a web app atm is to only use DAOs in the view layer and doing optimistic locking detects manually. This just sucks.

        As for the JPA vendors:
        I'm pretty sure that JBoss is interested to fix this. Especially since they heavily promote the entitymanager-per-conversation pattern which would then start to work.
        I'm OpenJPA committer myself, and I think this will also be welcome in our community.
        I've not much clue about EclipseLink, but as they afaik also store the state inside the Entities it should also be doable.

        Are there any other JPA vendors which are active in the JSR or have a bigger community?

        Show
        Mark Struberg added a comment - Hi Mike! Thanks for the honest answer. As I am EG member on other JSR myself, I certainly know those 'games'. This special issue has indeed a long history. I've seen EJB bug reports from 2005 (or even older?) which are originated in this very problem. And they all got bulk-updated and set to closed WITHOUT solving the underlying problem. But all this doesn't change the fact that this is still broken and users don't care about political games behind the scene. This is really one of the reasons why user turn away from JPA and use SpringData, iBatis and eBean instead. Currently the only way you can work with JPA in big projects is the old EJB transaction pattern where all entities get detached after the service invocation and NOT get used anymore in JSF pages or even JSF backing beans. But exactly that is what most EE6 samples currently showcase - despite being broken. This also renders JSR-303 mostly useless. Really, the only way to use JPA in a web app atm is to only use DAOs in the view layer and doing optimistic locking detects manually. This just sucks. As for the JPA vendors: I'm pretty sure that JBoss is interested to fix this. Especially since they heavily promote the entitymanager-per-conversation pattern which would then start to work. I'm OpenJPA committer myself, and I think this will also be welcome in our community. I've not much clue about EclipseLink, but as they afaik also store the state inside the Entities it should also be doable. Are there any other JPA vendors which are active in the JSR or have a bigger community?
        Hide
        ldemichiel added a comment -

        Well, we tried to resolve this via a proposal based on entity graphs, but could not achieve closure. This is something that we should revisit in JPA.next.

        Show
        ldemichiel added a comment - Well, we tried to resolve this via a proposal based on entity graphs, but could not achieve closure. This is something that we should revisit in JPA.next.

          People

          • Assignee:
            ldemichiel
            Reporter:
            Mark Struberg
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: