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. > 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. > 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 ) ... Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
