Mika Goeckel wrote:
>
[ snip ]
> >
> > I'm not saying this is necessarily a "good" idea, but you can byte
> > compare the resulting session serialization to see if the session
> > objects have changed. All you have to do is keep a local copy of
> > the original session during the request. Not very pretty, but
> > is a solution that wasn't discussed.
> >
> > I tend to agree with Costin that the session API isn't well suited
> > for failover/distribution. I don't think it's impossible though.
> > Plus, if you decide to develop an API separate from the session...
> > it really starts to look like EJB.
>
> 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
> 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.
For what it's worth, I completely agree. Failover is _never_
something that the app developer can completely ignore... no matter
how much functionality the container provides. Developing
distributed applications takes a little thought at the very least.
And failover is just a simple distributed model.
I've been reading all of this with great interest and waiting to see
where it settles. I have alot of experience with various forms of
distributed applications and it's interesting to see where they are
similar. I'm really tempted to explore how a jini solution might
be architected... just from the curiousity side more than anything.
(I've been looking for a good excuse to dive deeper into jini.)
>
> 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.
Interesting. I hadn't thought about differential updates using
serialized streams. They tend to be kind of random but it might
work. Also, I have written some classes before that can decode the
binary streams as meta-data and now I'm thinking there might even be
a clever diff that can be done by actually interpretting the data
during the diff. I'll have to think about that some more.
>
> 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.
Agreed.
-Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
