Hi all, I agree with both of you, but I can state that our developers love to work with TOMCAT and APACHE and I would like to suggest to implement failover- and loadbalacing techniques although not required by the specs.
We've started with NAS/iPlanet and EJBs two years ago. Now we are developing with JSPs and SERVLETs 'only' (due to performance constraints) and our developers want us to use TC in production as well. I can only support that if we will be able to cluster TC and have session failover as well. TC is easy to work with, easy to understand and 100% spec. compliant what iPlanet for example isn't (at the moment). Will TC evolve in that direction in future or will it stay an impressive spec. reference ? Thanks for any comments ! Oliver > AXA eSolutions GmbH > AXA Konzern AG Germany > Oliver Lauer > Web Architect > Wörthstraße 34 > D-50668 Köln > Germany > Tel.: +49 221 148 31277 > Fax: +49 221 148 43963 > Mobil: +49 179 59 064 59 > e-Mail: [EMAIL PROTECTED] > _____________________________ > -----Ursprüngliche Nachricht----- Von: Mika Goeckel [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 14. November 2001 11:26 An: Tomcat Developers List Betreff: Re: Tomcat: Distributed Session Management revisited ----- 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]> ---------------------------- Aus Rechts- und Sicherheitsgruenden ist die in dieser E-Mail gegebene Information nicht rechtsverbindlich. Eine rechtsverbindliche Bestaetigung reichen wir Ihnen gerne auf Anforderung in schriftlicher Form nach. Beachten Sie bitte, dass jede Form der unautorisierten Nutzung, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail nicht gestattet ist.Diese Nachricht ist ausschliesslich fuer den bezeichneten Adressaten oder dessen Vertreter bestimmt. Sollten Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein, so bitten wir Sie, sich mit dem Absender der E-Mail in Verbindung zu setzen. ---------------------------- For legal and security reasons the information provided in this e-mail is not legally binding. Upon request we would be pleased to provide you with a legally binding confirmation in written form. Any form of unauthorised use, publication, reproduction, copying or disclosure of the content of this e-mail is not permitted. This message is exclusively for the person addressed or their representative. If you are not the intended recipient of this message and its contents, please notify the sender immediately. --------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
