geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: [clustering] -- HttpSession and EJB Session
Date Fri, 22 Aug 2003 06:59:54 GMT
Alex Blewitt wrote:

> 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 :-)]

Alex,

I am not looking for the path of least resistance to a distributable 
httpsession impl - I already have one :-) I'm trying to improve it....

As soon as the Jetty integration settles down and I can find the time, I 
will either port or rewrite (probably a bit of both) my current impl. If 
I'm going to be doing major surgery on it, then I want to carefully 
reconsider everything that I learnt from the last iteration, or can 
squeeze out of the great minds on this list and put that in too ...

If you like the idea of a SessionBean based impl - have a look at 
Jetty's org.mortbay.j2ee.session.AbstractStore and CMPStore and figure 
out how you could write an e.g. SFSBStore... I'm sure I would be happy 
to accept it into the fold.

>
>
>> 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. 

I'm sure someone has distributed XAs on their todo list :-)

>
>
>>> 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) system.

I already have two impls. Personally I think 'in-memory-replication' is 
the way to go.

>
>>> 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). 

exactly - my replication is done on a per-attribute basis

>
>
>>> 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 ?)...
>
>
> 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. 

OK - we'll call it in-memory-replication

>
>
>>> 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). 

as much code as is practicable will be shared between the impls. I think 
session EJBs have not been mentioned because they are a solved problem. 
Jeremy is probably making mental notes of everything from this thread 
that can be used in common, as I hope other readers are also doing...

Jules

>
>
> Alex.
>


-- 
/*************************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * http://www.coredevelopers.net
 *************************************/



Mime
View raw message