[EMAIL PROTECTED] wrote:
>
> 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.
I think the idea is that you'd byte compare on "commit" which ideally
would happen at request boundaries. So in this case a single request
becomes a "transaction"... which indeed opens up its own issues, but
no bigger than the ones that were always there.
The main issue is that the app has no control over this transaction.
The case where things get strange is if the JVM dies in the middle
of processing a single request. The request may have already
committed real data to the DB, app server, whatever... and yet the
session state up to the point of failure would be lost. Even five
second polling wouldn't fix that case.
In fact, that's the same case that fails in _every_ scenario that
doesn't involve full EJB-like transaction support. As soon as you
access one single piece of data that isn't covered by the
transaction support, you lose some amount of failover recovery.
Nothing short of full transaction support will ever cover the case
of the dying JVM... and in some rare cases I think that will even fail.
That being said, there may still be a place for a session-based
distribution mechanism that can support load balancing, hot-swapping
of tomcats, and basic failover. It should definitely be an opt-in
sort of thing though, ie: web apps that meet the restrictions can
opt to setup tomcat to provide this feature.
>
> > 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 ) ...
I agree... in these cases, the webapp could not be used with a
distributed session environment. I think that's a given. Personally,
I'm still trying to figure out if there are a large enough number
of webapps that could be supported to make it worth the effort.
(Heavy emphasis on effort.)
-Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
