[jboss-as7-dev] EJB passivation/activation, clustering and JPA extended persistence context handling...

[Scott Marlow]

Yeah, the graph could be deep.  If we are replicating SFSB1 which is 
sharing an extended persistence context with SFSB2 and SFSB2 shares a 
separate extended persistence context with SFSB3 (and so it 
continues...).  I don't think this is the likely 95% case but still 
possible.

I'm open to alternative solutions.

For fail-over to work, I think that all of the SFSBs in the graph, will 
also need to be available on the node that we fail over to.  If we were 
to replicate them as a group, we could optimize the serialization of 
shared XPCs to only be sent once.  I'm not saying that is the way we are 
going to do the SFSB level clustering, just pointing out that knowledge 
about the XPC use could be obtained through the proposed SPI (if we were 
to do it that way).  I think we could handle replicating the SFSB graph 
entries individually and I can deal with that, if needed.

Currently, we have the ExtendedEntityManager that is a proxy to the 
underlying entity manager.

https://github.com/jbossas/jboss-as/blob/master/jpa/core/src/main/java/org/jboss/as/jpa/container/ExtendedEntityManager.java 
is the current implementation on AS7 master.

https://github.com/scottmarlow/jboss-as/blob/2292b8393c1f32e23d949c728022db45a1ea6bee/jpa/core/src/main/java/org/jboss/as/jpa/container/ExtendedEntityManager.java 
is an UUID based variation of the ExtendedEntityManager (on a cluster 
branch).

For the passivation of SFSBs, I think the entire XPC inheritance derived 
graph could be passivated.  If one of the SFSBs cannot be passivated 
(because its in a transaction, in use or perhaps has an extended 
persistence context entity that isn't serializeable), I wouldn't expect 
any of the SFSBs to be serialized.

On 10/24/2011 02:57 PM, Carlo de Wolf wrote:
> I think its better to treat a clustered XPC as an 'individual SFSB'.
> Trying to maintain a graph around one XPC can quickly become very messy.
> Especially if different XPCs get involved. Conceptually the XPC can
> behave similar as a SFSB and we just keep proxies as references to it.
> Then it can replicate "at whim".
>
> Carlo
>
> On 10/24/2011 06:10 PM, Scott Marlow wrote:
>> On 10/24/2011 11:17 AM, Brian Stansberry wrote:
>>> On 10/24/11 9:54 AM, Scott Marlow wrote:
>>>>
>>>> On 10/24/2011 10:47 AM, Brian Stansberry wrote:
>>>>> Throwing NotSerializableException instead of serializing means removing
>>>>> support for clustering SFSBs with an XPC. That IMHO would be a pretty
>>>>> major feature regression. I believe we have supported that since AS 4.2
>>>>> if not earlier.
>>>> I don't disagree, was just interested in hearing from anyone that
>>>> thought we shouldn't do this and why. I appreciate the feedback that we
>>>> should do it. :)
>>>>
>>> Paul had done a bunch of cool stuff around XPC serialization that he had
>>> to put on the back burner to focus on the AS 6 Infinispan integration.
>> I think that Paul has been continuing the ideas presented in
>> http://community.jboss.org/wiki/DevEJB3NewSFSBCache for the SFSB
>> clustering (Paul?), but some changes will be needed for clustering the
>> extended persistence context.
>>
>> The knowledge of the group of SFSBs related to a single SFSB (through
>> its XPCs, is available in the JPA subsystem and can be exposed via the
>> XPCSerializationController SPI.  If the SPI is wrong, lets correct it.
>>
>> If we cannot use the SPI for clustering, I'll remove the clustering
>> aspects from it, but I'm hoping that won't be the case.
>>
>>>>> On 10/24/11 9:39 AM, Scott Marlow wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm looking into handling serialization of the extended persistence
>>>>>> context (for both clustering and EJB3.1 passivation/activation).
>>>>>>
>>>>>> The (JPA subsystem) spi is still developing for this but if anyone has
>>>>>> feedback or wants to follow. A sketch for the spi is at
>>>>>> https://github.com/scottmarlow/jboss-as/blob/d7ec51ac14afb47ced7d203f8b3696c10221e9db/jpa/spi/src/main/java/org/jboss/as/jpa/spi/XPCSerializationController.java
>>>>>>
>>>>>>
>>>>>>
>>>>>> One question that comes up is why. Why not just throw
>>>>>> NotSerializableException instead of serializing the extended
>>>>>> persistence
>>>>>> context. If anyone feels strongly that we should throw
>>>>>> NotSerializableException instead of serializing the extended
>>>>>> persistence
>>>>>> context, I'd like to hear why.
>>>>>>
>>>>>> I've made internal changes on
>>>>>> https://github.com/scottmarlow/jboss-as/tree/cluster1 to support
>>>>>> clustering extended persistence contexts. Next is to do the actual
>>>>>> serialization.
>>>>>>
>>>>>> Scott
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>
>>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev