-
1. Re: Redesign extended persistence context
brian.stansberry Aug 27, 2007 4:10 PM (in response to wolfc)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
wolfc Aug 28, 2007 4:58 AM (in response to wolfc)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 Aug 28, 2007 9:11 AM (in response to wolfc)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
wolfc Aug 28, 2007 9:35 AM (in response to wolfc)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 Aug 28, 2007 9:41 AM (in response to wolfc)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
wolfc Aug 28, 2007 10:55 AM (in response to wolfc)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 Aug 28, 2007 5:49 PM (in response to wolfc)"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 Aug 28, 2007 8:37 PM (in response to wolfc)"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 Aug 28, 2007 8:39 PM (in response to wolfc)"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 Aug 28, 2007 8:40 PM (in response to wolfc)"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
wolfc Aug 29, 2007 8:08 AM (in response to wolfc)"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 Aug 29, 2007 11:23 AM (in response to wolfc)I thought we were serializing the entire XPC with the SFSB? What is wrong with that approach?
-
13. Re: Redesign extended persistence context
wolfc Aug 29, 2007 1:11 PM (in response to wolfc)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 Aug 29, 2007 1:26 PM (in response to wolfc)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.