[cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl
Martin Kouba
mkouba at redhat.com
Tue Oct 13 02:44:01 EDT 2015
Dne 12.10.2015 v 23:56 Emily Jiang napsal(a):
> Thank you Mark for the useful information! I forgot to cc cdi-dev:(.
> Yes, I meant the session failover in a cluster containing multiple servers.
> From what you described, it seems the session failover can only occur
> among the servers containing the same level of OWB. It is going to be
> very tricky to get OWB 1.0/1.1 to failover to OWB 1.2 servers. The
> serialization/deserialization is very different.
>
> I believe in Weld, the Weld generated subclass is stored in the session.
> Martin K, please correct me if I am wrong.
Well, not exactly. Weld stores a contextual reference (subclass), a
creational context and some info about the contextual (a bean, its id,
etc.). You always need these to destroy a contextual instance properly.
And it's not compatible between weld 1.1 and 2.0+. First of all in weld
1.1 javassist is used but in 2+ it was replaced by
jboss-classfilewriter. Also there are some optimizations in the
contextual info part.
>
> To move forward, can we work out a plan to support failover among
> different CDI levels of the same kind in the future CDI releases as the
> current failover support is a real limitation?
>
> On Mon, Oct 12, 2015 at 9:29 AM, Mark Struberg <struberg at yahoo.de
> <mailto:struberg at yahoo.de>> wrote:
>
> Deliberately private? Or did you simply forget to cc cdi-dev? Feel
> free to forward my answers to the list.
>
>
> > The EJB spec does not say anything about failover.
>
> Yes it says nothing about session failover or session replication.
> It is pretty vocal about remoting however. And this is
> technologically very close to clustering on many servers (Server
> talking to another Server).
> We probably have to explicitly distinguish a simple Session failover
> to a functional clustering aka scale up (mostly @Remote).
>
> Guess you are just refering to the former, right?
> For EJBs you can also only have @Stateful beans affected by session
> replication. And only if you store them in the Session (which gets
> replicated) of course. Or since EE6 if they are annotated with a CDI
> Scope annotation which ends up in the http session along the line
> (@SessionScoped, @ConversationScoped, various custom scopes, e.g.
> DeltaSpike @WindowScoped or @ViewAccessScoped). Or an @Dependent
> @Stateful which gets injected in a bean which ends up in the
> HttpSession.
> Any other EJBs which might get moved to another cluster node as a whole?
>
> Re OWB 1.1 and 1.2 compat. I fear it’s not easy. The ‚Contextual
> Instance‘ stored in OWB-1.1 is _always_ without any interceptors or
> decorators. It doesn’t even contain any javassist dependencies. BUT
> if you inject any other NormalScoped bean into it _THEN_ you will
> have the ‚proxy shale‘ for those. And they of course contain
> javassist classes.
>
> In OWB-1.0 and 1.1 we also had a single ‚unified‘ proxy stack which
> contained NormalScoping, Interceptor logic and Decorator logic.
> In OWB-1.2 and up we did split this and now have 3 different
> proxies: NormalScoping proxies aka the ‚Contextual References‘. They
> are _not_ part of the Contextual Instance. Then we have
> Interceptor/Decoratpr Proxies (both in a single proxy class) and for
> abstract Decorators we also generate a simple proxy which just
> implements the missing methods. The later 2 proxies are part of the
> ‚Contextual Instance‘ and thus get stored in the
> ContextualInstanceBag/SessionContext in the HttpSession.
> And of course you have the same impact of injected NormalScoped
> beans into a e.g. @SessionScoped bean as with OWB-1.1.
>
>
> I guess that wou will get hit with similar constellations in Weld as
> well.
>
>
> LieGrue,
> strub
>
>
>
>
> > Am 11.10.2015 um 22:28 schrieb Emily Jiang
> <emijiang6 at googlemail.com <mailto:emijiang6 at googlemail.com>>:
> >
> > The EJB spec does not say anything about failover. Some EJB
> implementations can support failover between different server
> levels. I am talking about failover among the same kind. I don't
> believe OWB can support failover between cdi 1.0 and cdi 1.2,
> neither does Weld can do.
> >
> > On Fri, Oct 9, 2015 at 12:53 PM, Mark Struberg <struberg at yahoo.de
> <mailto:struberg at yahoo.de>> wrote:
> > Wonder the same. I’m 100% sure that it is NOT portable for NIV.
> Wheras for EJB2 style EJBs it _might_ working due to RMI/IIOP
> (Though don’t remember whether this was only specified for remoting
> or also for clustering. Nor do I remember if the spec said anything
> about clustering at all).
> >
> > I guess there often is ‚additional‘ wrapper stuff handed over in
> addition to the normal beans for EJB3 style EJBs. I know for sure
> that we do exactly that in OpenEJB. We have additional wrappers e.g.
> for transported Exceptions when doing remoting. We hand over the
> ’string representation’ and the original Exception stack data
> separately. In case we cannot de-serialize the Exception on the
> other side. Think about sending some OptimisticLockException (or
> even some internal Hibernate Exception) over to an EJB client which
> doesn’t have any Hibernate jars and not even the jaa-spec jar on
> it’s classpath… Similar additional information might be stored in
> any EJB proxy. Or think about Extended Persistence Contexts. How
> should that ever work to be serialized between e.g. WildFly and
> Glassfish? How would you replicate over some Hibernate Exception if
> the other node is running Glassfish with EclipseLink? :)
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 09.10.2015 um 12:54 schrieb Martin Kouba <mkouba at redhat.com
> <mailto:mkouba at redhat.com>>:
> > >
> > > I wonder whether this behavior is defined somewhere, i.e. if
> all EJB
> > > implementations must support "failover" between minor versions
> (e.g. EJB
> > > 3.0 and 3.2), in other words the passivation mechanism may not
> change.
> > > This would mean that an EJB app might be deployed to a "cluster" of
> > > mixed Java EE 6 and Java EE 7 app servers - seems to me like an
> > > extremely risky experiment.
> > >
> > > Martin
> > >
> > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a):
> > >> I am investigating the HttpSession failover for SessionScoped or
> > >> ConversationScoped beans. I think it is not easy to failover
> from the
> > >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of
> the raw bean
> > >> was serialised and the proxies are different between cdi 1.0
> and cdi
> > >> 1.2. Has anyone have any thoughts on this? If not possible,
> this is a
> > >> big limitation for CDI as EJB container has no such limitation.
> > >>
> > >> --
> > >> Thanks
> > >> Emily
> > >> =================
> > >> Emily Jiang
> > >> ejiang at apache.org <mailto:ejiang at apache.org>
> <mailto:ejiang at apache.org <mailto:ejiang at apache.org>>
> > >>
> > >>
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>
> > >> Note that for all code provided on this list, the provider
> licenses the code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
> > >>
> > >
> > > --
> > > Martin Kouba
> > > Software Engineer
> > > Red Hat, Czech Republic
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider
> licenses the code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider
> licenses the code under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> ideas provided on this list, the provider waives all patent and
> other intellectual property rights inherent in such information.
> >
> >
> >
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang at apache.org <mailto:ejiang at apache.org>
>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
More information about the cdi-dev
mailing list