More about XPC clustering below. ;)
On 11/11/2011 10:32 PM, Scott Marlow wrote:
A related question, I'm trying to get up to speed on what
internal state
needs to be replicated, for SFSBs that reference extended persistence
context. This will help me review some clustering code that is coming
together in this area. I think we need to replicate the following but
want to see what else needs to be covered:
- The stateful session bean attributes as represented by the EJB container.
- The extended persistence context as represented by the JPA
container/subsystem.
- The JPA SFSBXPCMap which can map a SFSB to collection of extended
persistence contexts that directly referenced. Can also map a extended
persistence context to collection of SFSBs that reference it.
- The JPA interceptors associated with each stateful session bean, need
to be ready to fire after fail-over has occurred (e.g.
SFSBDestroyInterceptor needs to fire when SFSB @Destroy is invoked after
a fail-over).
- Are there other interceptors associated with the SFSB that also need
to be replicated?
- Any other state for stateful session beans that is held externally to
the SFSB instance?
- Which SFSB classes are to be replicated with the SFSB? The
StatefulSessionComponentInstance?
We also know that we need to replicate the serialization group (as its
definition changes dynamically). For example, the application has five
stateful session beans (SFSB1-SFSB5) that are associated with three
extended persistence contexts (XPC1-XPC3). The relationships between
these five beans are as follows:
SFSB1 uses XPC1
SFSB2 uses XPC1 and has reference to SFSB3
SFSB3 uses XPC2
SFSB4 uses XPC2 and has reference to SFSB5
SFSB5 uses XPC3
When SFSB1 fails over, we need to fail-over its working set (the
serialization group which includes SFSB1, SFSB2, SFSB3, SFSB4, SFSB5,
XPC1, XPC2, XPC3). In case its not obvious why, SFSB2 may have pending
database updates in XPC1, so it must fail-over also to the same target
node. Since SFSB2 has a reference to SFSB3, SFSB3 needs to fail-over
together with the group also (and so the pattern continues for SFSB4,
SFSB5, XPC3).
The above is the application correctness issue. If SFSB2 fails over to
a different node than SFSB4, the extended persistence context could be
used on two different nodes. Basically, the extended persistence
context can live through several non-transactional invocations. When a
transaction is finally started on SFSB3 or SFSB4, the XPC2 changes will
finally be committed.
We need to have a load balancing policy that knows how to fail-over the
beans in the serialization group, as a group. So, that all requests to
any of the beans, always run on the same target node (else we can have
the same pending database changes applied from multiple nodes).
We also need the serialization group to be complete.
Scott
Thanks for any answers, this will help me review the clustering code
like I said and also think about ways to support the extended
persistence context replication. These are some of the questions that I
am asking myself but wanted to open the process up for input from others
that probably know better. ;)
Scott
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.
>
> 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/d7ec51ac14afb47ced7d203f8b36...
>>
>> 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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev