9:24 a.m.
On 12/02/2011 05:27 PM, Brian Stansberry wrote:
On 12/2/11 4:22 PM, Scott Marlow wrote:
> On 12/02/2011 04:38 PM, Jason T. Greene wrote:
>> On 12/2/11 2:55 PM, Scott Marlow wrote:
>>>> 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.
> >> I still don't this is right. those references go
across a proxy, and the
>> proxy's backing data can be anywhere.
> > I should of added that SFSB2
has a local reference to SFSB3 (which means
> they originates on the same JVM). I assumed that SFSB2 is migrated to
> the same target node as SFSB3 to keep the reference local (during a
> fail-over). No matter, where SFSB3 goes, SFSB4 needs to be on the same
> node (to share the same extended persistence context).
> The SFSBs themselves, can be anywhere but the extended
persistence
> context, needs to stay with the SFSBs that inherit it.
> Maybe there is another way to tackle this that I'm not
seeing but I
> wanted to mention these details to whomever is following this thread.
BTW, is there any spec requirement that prohibits concurrent access to
an XPC?
Yes, section 7.2 seems to cover that (they are not expected to be
thread-safe).
JPA 2.0 specification section 7.2 Obtaining an EntityManager:
"
An entity manager must not be shared among multiple concurrently
executing threads, as the entity manager and persistence context are not
required to be threadsafe. Entity managers must only be accessed in a
single-threaded manner.
"
The XPC usage model for sharing instances between SFSBs is described by
section 7.6.2.1 Inheritance of Extended Persistence Context:
"
If a stateful session bean instantiates a stateful session bean
(executing in the same EJB container instance) which also has such an
extended persistence context, the extended persistence context of the
first stateful session bean is inherited by the second stateful session
bean and bound to it, and this rule recursively applies—independently of
whether transactions are active or not at the point of the creation of
the stateful session beans.
If the persistence context has been inherited by any stateful session
beans, the container does not close the persistence context until all
such stateful session beans have been removed or otherwise destroyed.
"