----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, November 14, 2001 12:26 AM Subject: Re: Tomcat: Distributed Session Management revisited
> On Tue, 13 Nov 2001, Mika Goeckel wrote: > > > I completely agree, that the API lacks proactive support for things in the > > background that may fail. > > But given the fact, that we support a reference implementation which has > > managed to provide really professional services to users (other ref > > implementations are just for demonstration, nobody would use them in > > production) and there are (commercial) solutions, that provide session > > fail-over in the limitations of this API, we **must** try to provide a > > Well, the cool thing about open source is that we _don't_ need to > implement all the bloat that commercial solution have. Costin, I don't disagree with your opinion. We don't need to, because we work on a voluntary base. But don't you think that having the option to provide better or at least equally professional solutions is a good motivation? > > solution. The API does not specify, how often the container may try to > > provide that service or what means it utilizes to do that. Nothing is 100% > > and I think it is better to live with the uncertaincy we discuss here than > > with the more likely problem that an instance fails and there is no > > potential replacement. > > I think it's better to live with the certaincy that everything can ( > and will ) fail and tomcat can't change this. > > The alternative is to give users the impression the data he puts in a > session will be safe - and he may rely on that instead of using a > transaction and a real API. > > Databases, EJB, etc are complex - but there's a reason to that. Well, > we could argue about how much compexity is actually needed, but > one thing is certain ( I hope ) - get/setAttribute is not enough, if you > want data integrity you must use a different API ( in particular > transactions ). > > > > Byte-comparison is not the worst solution. If we think about differential > > updates, byte comparison is a good candiate for that and surplus one that > > promises good performance. > > Byte compare every 5 seconds every object in session ? Let's say you just > displayed the confirmation and charged the credit card, but the machine crashed just > before you sent the order. ( or reverse - you sent it but didn't charged > the credit card ). This should happen in below 5 seconds. Yep, but a single stand-alone instance is not invulnerable to that scenario. In fact a thoroughly designed cluster gives better chances. > > If the user wants to place things in a session that she does not need to be > > replicated, she has the option to declare them transient and write a getter > > that checks if the Attribute is present, otherwise reconstructs it (in the > > case of a picture, reloads it from disk). The user has the choice to design > > for performance or ease. We only need to document the options. > > So the user should change all his objects to implement some arbitrary > pattern just to fit this into our solution ? > > What if the object is not user defined ( like most are ) ? Well, we > have to create wrappers for each objects you store in a session. Try to > explain this on tomcat-user ( or tomcat-dev ) ... If the only alternatice is to use a professional EJB server, he would need to change them as well. I don't say he has to mark these values transient, it's only an option. And transient is not an arbitrary option, it's core java since JLS1.1 (1998). Sessions have always been somewhat fragile, but as the container is free to use transactions when the session is passed to another instance, at least that can be made secure enough. So the guarantee to the user of the container would not be made weaker. If the transaction fails, the session stays with the JVM where it originally was. The fail-over functionality would not be possible, but the situation to the app-developer would stay stable. I think that the documentation must clearly communicate to app-developers the risks and shortfalls of a distributed application and then let them choose by themselves what best meets their requirements. Mika -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
