geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [clustering] -- HttpSession and EJB Session
Date Fri, 22 Aug 2003 08:55:24 GMT
Comments on BEA Weblogic included below..

-----Original Message-----
From: Alex Blewitt []
Sent: 21 August 2003 22:59
Subject: Re: [clustering] -- HttpSession and EJB Session

On Thursday, Aug 21, 2003, at 10:11 Europe/London, Jules Gosnell wrote:

> The reason we are cracking the HttpSession nut first is because, 
> that's the bit I know about :-) and IMHO, it is by far the most tricky 
> of the two - why ?
> 1. Session EJBs were designed from the ground up with distribution and 
> all that that entails in mind - HttpSessions were not.
> 2. With EJB clustering we have total control of the LB. It will 
> probably be a smart client-side proxy - with HttpSessions we don't. It 
> will be a 3rd party black box with varying fn-ality.
> 3. People expect to take a hit in performance when the move data from 
> a POJO to an EJB, with an HttpSession they don't

Possibly true to all of these. However, I was pointing out that if the 
SessionBean nut was cracked, then it would be trivial to implement 
HttpSessions on top of SessionBeans. [It probably wouldn't be the most 
efficient way, for sure :-)]

> I always like to break the back of the hardest part of a problem 
> first, rather than invest a lot of time travelling down a path, 
> turning a corner and finding an insurmountable brick wall there... :-)

True. Always good to know what's possible, rather than walking down a 
blind alley. Right up until you start writing JavaMail ...

> Perhaps you should start an EJB clustering thread ?

Possibly a good idea, but I'm taking a look back at clustering in 
general rather than being involved with EJBs specifically at this point 

>> It's no good using a web application and for it to fall over to 
>> another node if that web app was using SessionBeans and it looses its 
>> session state.
> it won't-
> you put the bean into your httpsession (it will store a distributable 
> handle).
> you take it out on another node (the handle is turned back into a 
> remote proxy)
> you talk through it to your remote resource...

Sorry, I should have been a bit more descriptive :-) I was assuming 
that the SessionBean stayed in memory (remember, SessionBeans aren't 
backed by a DB in the same way that EntityBeans are) and was in the 
machine that crashed.

Secondly, if you do get a handle to the SessionBean (and the handle has 
been replicated to another machine) then the SessionBean will still 
refer back to the crashed machine anyway ... (at least, until EJB 
SessionBean clustering has been solved ;-)

> as above, but the session bean is also replicated to the node you fail 
> over to and the containers agree an optimisation underneath the covers 
> so that when conversation is reprised on the failover node, it is all 
> done locally....

Yes, that is possible, but with the nature of transactions as well that 
may become more complex.

>> The approach taken by WebSphere is to serialise the SessionBean in 
>> addition to the HttpSession out to an external system, and then load 
>> it when required. Not only is this a simple solution, but the same 
>> techniques can be applied for both HttpSession and SessionBean 
>> clustering.
> We've already done this model - it's 'shared-store'

Yup, it's been talked about. Was it decided that this wouldn't be 
implemented, or it might be implemented later? Most of the recent 
conversations on clustering seems to be discussing the buddy(ies) 

>> I fear that the HttpSession will work based on very intimate details 
>> of how the HttpSession works (which is in Geronimo's control), 
>> whereas this will not be possible with SessionBeans to the same 
>> extent.
> the behaviour of HttpSession is defined in the servlet spec and that 
> of session beans in the EJB spec - neither are under our control, we 
> just have to come up with an impls for both which share as much code 
> between themselves as is useful.

Yes, it's true that they don't have to use the same system. However, I 
wanted to call attention to the problem to see if there was a common 
way forward that would make sense. For example, SessionBeans can pretty 
much only use serialisation to get between machines, whereas the 
HttpSession stuff you can get at the modifications at a much lower 
detail (access of individual parameters, for example).

>> Have you considered representing the HttpSession as a SessionBean and 
>> then working on only one solution to the clustering problem from the 
>> SessionBean end? Then you would have a solution that fits both, and 
>> whilst the in-memory replication process/buddying system works well 
>> for HttpSession, I feel that this approach won't be suitable for 
>> SessionBeans.
> see above.
> BTW, JBoss currently uses replication for clustered stateful session 
> beans. As, I think, WebLogic does (can anyone confirm this ?)...

Weblogic comments:  Weblogic copies session states between all nodes in a cluster.  This does
not rely on a buddy system as such, but means that in event of a failure, any of the nodes
can continue.  As far as I am aware, this works for both HTTPSessions and SessionBeans.

WebSphere does this by commiting this information to a persistent data source (typically a
database).  Not sure if WebSphere V5 does this differently, but if it does, I expect that
it uses a similar approach to Weblogic.

IMHO the term 'replication' is still somewhat vague -- it defines a 
family of processes, rather than the in-memory replication which it is 
currently being used as. I think it would be a good idea to call it 
something specific (in-memory replication, or something better that I 
can't think of right now :-) so that when JavaDocs/User guides etc. are 
written the terms are unambiguous.

>> On the other hand, a solution for SessionBeans will implicitly work 
>> for HttpSession as well.
> if you want to hobble your use of HttpSessions with all the additional 
> aspects of session bean use, like remote semantics, single 
> threadedness etc, yes. The HttpSession's local semantics make life 
> really awkward.

I'm not sure that the remote semantics are 100% necessary when working 
with EJBs, though they can do. I'm also unconvinced that the 
single-threadedness needs to be mandated either; if the EJB is running 
locally then there are all sorts of optimisations that can be done on 
an EJB. If the SessionBean doesn't use transactions, then there 
wouldn't be any issues with multi-threading IMNSHO.

But in any case, I wasn't (necessarily) thinking of suggesting 
HttpSession-> SessionBean -> session service, more like HttpSession -> 
session service <- SessionBean, so there was a common area in between. 
Something like serialisation would work for both; it would just be a 
case of 'when the user has finished with it (i.e. at the end of the 
web/ejb request as appropriate).




View raw message