1 2 Previous Next 23 Replies Latest reply on Apr 2, 2008 1:42 PM by Brian Stansberry

    Redesign extended persistence context

    Carlo de Wolf Master

      http://jira.jboss.com/jira/browse/EJBTHREE-1026

      I'm working to refactor the extended persistence context to fully allow the SFSBs to have an independent life cycle and fix some bugs with replication of 'nested' SFSBs.

      What I think will work out is having the XPC behave the same way as a SFSB. For this purpose I've committed a proof of concept (unit test xpcalt).
      As can be seen the XPCAltBean behaves quit nicely before and after passivation. To allow inheritance of an XPC I've already got an XPCHolder in my workspace (removing the weird injection constructs). And with the decoupled life cycle the weird NestedStatefulBeanContext and ProxiedStatefulBeanContext are a thing of the past.
      I haven't tried out clustering yet, but with serialization working that should not be an issue.
      The issue that will pop up is the configuration of an XPC SFSB construct.

      Flame away.

        • 1. Re: Redesign extended persistence context
          Brian Stansberry Master

          The replication optimization stuff I mentioned in last week's team call are discussed at

          http://jira.jboss.com/jira/browse/EJBTHREE-1039
          http://jira.jboss.com/jira/browse/JBAS-4629
          http://jira.jboss.com/jira/browse/JBAS-4630

          BTW, I haven't looked at the xpcalt stuff in great detail, but one thing I don't see is any SFSB holding a ref to a managed entity across replication or passivation/activation. There needs to be object identity maintained between any such entity and the entity stored in the XPC. I don't know if what you're working on will handle that well or not.

          That said, an independent lifecycle for XPCs certainly sounds good.

          • 2. Re: Redesign extended persistence context
            Carlo de Wolf Master

            Passivation/activation isn't a problem, because by definition we only passivate if the entities are serializable (EJB 3 4.2) and we treat the entity as a serializable object. Thus the entity becomes detached after activation (JPA 3.2.4). All working according to spec.

            Replication is a problem. Not so much for a transaction scoped persistence context, because you can only replicate over transactions and not within. Thus the entities becomes detached. But I agree that a XPC has a problem if a SFSB keeps a reference to an entity.
            As long as we do a passivation/activation cycle during replication, we're okay because the first paragraph applies.

            • 3. Re: Redesign extended persistence context
              Bill Burke Master

              This doesn't seem right....Entities become detached before/after passivation/activation of a SFSB? This means you cannot have any managed entities as fields of your SFSB, or rather it is unreliable to do so if your container may passivate.

              • 4. Re: Redesign extended persistence context
                Carlo de Wolf Master

                If passivation implies serialization then according to JPA spec the entity becomes detached.
                EJB 3 4.2.1 allows for a reference to a serializable object, not a keep-alive managed entity.

                • 5. Re: Redesign extended persistence context
                  Bill Burke Master

                  I don't think your interpretation is correct. Otherwise, extended PC would be entirely useless. The whole point of extended PC is to keep managed objects around.

                  • 6. Re: Redesign extended persistence context
                    Carlo de Wolf Master

                    The spec doesn't state the intention of an extended persistence context. It only states the rules of a SFSB, entity and persistence context. Given those rules an entity drawn from a xpc and directly refered (from a field) by a SFSB must act as I said.
                    The only thing said about an extended persistence context is that it's life cycle is not bound by a transaction, but by the SFSBs that use it (JPA 3.3).
                    Why would you want to keep managed entities around?

                    • 7. Re: Redesign extended persistence context
                      Brian Stansberry Master

                       

                      "wolfc" wrote:
                      Given those rules an entity drawn from a xpc and directly refered (from a field) by a SFSB must act as I said.


                      JPA 3.2.4 says serializing an entity "may result" in a detached entity; it doesn't say it must. So, seems to me we have flexibility.

                      That said, a developer wanting to write a portable app would need to assume the container is going to detach the entity, since some vendors might. I take it the way an app developer would handle that would be to do a merge of all entities in the @PostActivate callback, correct?

                      Why would you want to keep managed entities around?


                      Assuming the idea here is this is supposed to resemble pojo programming as much as possible, why would an app developer not want to?

                      • 8. Re: Redesign extended persistence context
                        Gavin King Master

                         

                        "wolfc" wrote:
                        Passivation/activation isn't a problem, because by definition we only passivate if the entities are serializable (EJB 3 4.2) and we treat the entity as a serializable object. Thus the entity becomes detached after activation (JPA 3.2.4). All working according to spec.


                        This definitely not allowed by the spec. An entity should remain managed across passivation/activation.

                        • 9. Re: Redesign extended persistence context
                          Gavin King Master

                           

                          "bstansberry@jboss.com" wrote:
                          "wolfc" wrote:
                          Given those rules an entity drawn from a xpc and directly refered (from a field) by a SFSB must act as I said.


                          JPA 3.2.4 says serializing an entity "may result" in a detached entity; it doesn't say it must. So, seems to me we have flexibility.


                          When the JPA spec talks about serializing entities it is definitely not talking about any serialization that might happen during passivation (that is an implementation detail of the container and is not visible to, or part of the contract with, the application).

                          What it is talking about is entities returned by remote method.

                          • 10. Re: Redesign extended persistence context
                            Gavin King Master

                             

                            "wolfc" wrote:
                            If passivation implies serialization then according to JPA spec the entity becomes detached.
                            EJB 3 4.2.1 allows for a reference to a serializable object, not a keep-alive managed entity.


                            Passivation definitely does not imply serialization.

                            • 11. Re: Redesign extended persistence context
                              Carlo de Wolf Master

                               

                              "gavin.king@jboss.com" wrote:
                              Passivation definitely does not imply serialization.

                              EJB 3 4.2.1:
                              The Bean Provider is required to ensure that the PrePassivate method leaves the instance ?elds and the ?elds of its associated interceptors ready to be serialized by the container.

                              I like the 'may' bit of JPA. Now we amend that with our own:
                              Passivation and replication of an XPC and it's managed entities will not detach a managed entity.

                              Leaves us with the 'how do we do that?'

                              • 12. Re: Redesign extended persistence context
                                Bill Burke Master

                                I thought we were serializing the entire XPC with the SFSB? What is wrong with that approach?

                                • 13. Re: Redesign extended persistence context
                                  Carlo de Wolf Master

                                  Two things:
                                  1. The life cycle of all SFSB using that XPC are connected. Maybe we can limit that to just the passivation/activation.
                                  2. Partial replication should be possible.

                                  • 14. Re: Redesign extended persistence context
                                    Brian Stansberry Master

                                     

                                    1. The life cycle of all SFSB using that XPC are connected. Maybe we can limit that to just the passivation/activation.


                                    They are connected, yes, but it should be possible to independently remove the beans that use the same XPC with the existing mechanism. I'm quite certain I wrote tests for that. Admittedly, the way it works is ugly.

                                    2. Partial replication should be possible.


                                    What do you mean here?
                                    a) Partial replication of the XPC (i.e. unflushed changes)
                                    b) Fine-grained (PojoCache) replication of the SFSBs
                                    c) Independent replication of the SFSBs that share the XPC
                                    d) Something else
                                    e) All of the above.

                                    For A, Steve Ebersole is going to work on that at the Hibernate level.

                                    For C, the stuff discussed at http://jira.jboss.com/jira/browse/EJBTHREE-1039 can help with that. That is, alter the serialization of the bean so the the entity id is written to the stream rather than the entity. Ensure the XPC is deserialized before the bean. If we can solve that problem well, the need to serialize in one unit all the beans that use the XPC might be removed.

                                    1 2 Previous Next