11 Replies Latest reply on Aug 30, 2007 10:20 AM by porcherg

    basic persistence test

    porcherg

      I submitted a small persistence test (ProcessDefinitionTest)

      This test builds a process, persists it and then reloads it.

      I added a DbProviderTests files which can run the same db test suite with different Jpa implementation.
      Each implementation is defined in the environment xml.
      The tests works with hibernate and toplink (but toplink tests are commented because I don't know how to add the jar to the build.xml file as it is not in the repository)

      I added bindings in wire xml to create JpaPersistenceFactories and JpaPersistenceSessions.


      I have some questions:
      1- is there a link between an environment transaction and a PersistenceService ? can a PersistenceService be a Resource ? this way, the persisted objects would be flushed to the db when the environment is closed. If PersistenceService is not a Resource, when are the persisted objects flushed to the db ?

      2- I defined a persistence.xml file with the properties for all persistence providers. Is it better to define them in the environment xml ?

      3- Can we add other persistence providers to the repository ? This way we could verify that the persistence works on several implementations.


      regards,
      Guillaume

        • 1. Re: basic persistence test
          tom.baeyens

          i'll have a look asap and let you know my feedback. that might be monday, though.

          • 2. Re: basic persistence test
            tom.baeyens

            it looks awsome !

            i didn't knew the junit trick to run the same testsuite with different configurations. cool !

            is the next thing you're going to do db schema creation ? or something else ?

            • 3. Re: basic persistence test
              porcherg

              I updated the test and the OR mapping.

              I have some problems with the mapping:

              - What should be persisted in Environment and WireContext ?
              I had the problem with the ProcessElement configuration field (for the test, I just persisted the WireDefinition as a serialized object)

              - How to persist an ObjectReference ? (maybe this has a link with the previous question)

              - More generally, what should be persisted as a serialized object and what should be in a separate table ?

              regards,
              Guillaume

              • 4. Re: basic persistence test
                tom.baeyens

                 

                "porcherg" wrote:
                - What should be persisted in Environment and WireContext ?


                execution.environment should not be persisted

                "porcherg" wrote:

                I had the problem with the ProcessElement configuration field (for the test, I just persisted the WireDefinition as a serialized object)


                the configuration members in various process definition elements are still in flux, so they don't have to be persisted yet.

                but at some point, WireDefinition s will have to be persisted. this implies mapping all the descriptors. that is something that you could start on. when you do that, try to make sure that you re-use columns. meaning that if you have 2 different discriptors with both a String member field, make sure that they map to the same column. this will only work for basic types, but it already reduces the nbr of columns significantly.


                "porcherg" wrote:

                - How to persist an ObjectReference ? (maybe this has a link with the previous question)


                object references should have a memberfield that points to a descriptor. once the wire definitions, including the descriptors are mapped, that can be used.

                "porcherg" wrote:

                - More generally, what should be persisted as a serialized object and what should be in a separate table ?


                nothing should be a serialized object
                only the clob and blob objects will have binary info. but in that case, it's user information that is binary. no process information should ever be persisted in binary format.

                • 5. Re: basic persistence test
                  tom.baeyens

                  postLoad in node should be removed. the maps must be derived from the list in a lazy fashion. only when they are actually used. and then they must be cached until the list changes. at that point, the map caches should be nulled.

                  • 6. Re: basic persistence test
                    tom.baeyens

                    wirecontext must never be persisted, i think. only the wire definition and the descriptors

                    • 7. Re: basic persistence test
                      tom.baeyens

                      why is the close method added in persistence service ?

                      • 8. Re: basic persistence test
                        porcherg

                         

                        "tom.baeyens@jboss.com" wrote:
                        why is the close method added in persistence service ?


                        Hibernate implementation uses this method to close the connection and to free some resources.
                        JPA implementation uses this method to close the entitymanager

                        I use this method to close the PersistenceService before closing the Environment.

                        I think we should not have multiple persistence service that we never close.

                        If we have a link between the PersistenceService and the Environment, we could remove this method.
                        Can we define the persistence service as a resource enlisted to the environment transaction ?
                        This way the connection would be closed with the environment.

                        Guillaume

                        • 9. Re: basic persistence test
                          porcherg

                           

                          "tom.baeyens@jboss.com" wrote:
                          postLoad in node should be removed. the maps must be derived from the list in a lazy fashion. only when they are actually used. and then they must be cached until the list changes. at that point, the map caches should be nulled.


                          postLoad methods are just a copy of the readResolve methods because I didn't want to introduce modifications in the existing code.

                          I'll try to modify Process and Node so that they have the behavior you described.

                          Guillaume

                          • 10. Re: basic persistence test
                            porcherg

                             

                            "tom.baeyens@jboss.com" wrote:
                            FYI: Note that the eagerInitNames in WireContext are for persistence performance. In theory, we could just loop over all the descriptors and ask if they have to be eagerly initialized. But when hibernate loads the descriptors map, it returns a map with all proxies. They are only loaded the first time they are accessed. So if only 2 out of 10 objects have to be eager loaded, for the 8 others the descriptor will be initialized.


                            Rather than storing the name of the descriptor, I suggest that we store the descriptor itself.

                            If we store the descriptor, we can just load the descriptors we need for eager creation.

                            This solution would be easier to persist (it is difficult to store a list of strings with JPA) and will not generate more db data as the descriptor is already stored in the db (with the descriptors map)

                            I have tried to make the modifications locally, all the unit tests succeed.

                            What do you think of this modification ?

                            Guillaume

                            • 11. Re: basic persistence test
                              porcherg

                               

                              "tom.baeyens@jboss.com" wrote:
                              postLoad in node should be removed. the maps must be derived from the list in a lazy fashion. only when they are actually used. and then they must be cached until the list changes. at that point, the map caches should be nulled.


                              In the current implementation, the map caches are updated when the lists are modified.

                              Should we keep this implementation or should the caches be nulled ?

                              Guillaume