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 *************************************/
