Re: question about persistence
Gregg Wonderly <[email protected]>
| Newsgroups | gmane.comp.java.sun.javaspaces |
|---|---|
| Message-ID | <[email protected]> |
Shay Hassidim wrote:
> Building clustered highly available JavaSpaces is not so simple.
>
> We have invested and still investing great efforts building stable and
> reliable cluster aware JavaSpaces solution.
Hi Shay. As Dan commented, there are of course a lot of different strategies
for how to provide backup to data services. If the JavaSpace is a persistent
store that is the sole source for data in transit, then there are much more
complicated requirements on how it should handle data and how any backup of that
data should be handled. Also, if your data flow requirements for delivery are
"best effort", that is much easier than "at least once" which is much, much
easier than "only once with guarenteed delivery".
Many of the systems that I work with have required data delivery. However, they
handle "at least once" without problems, and the data flow parts of the system
can actually just be "best effort".
The reason is that the missing data is recognizable as being missing. And the
data source can be contacted to resend if needed.
In cases where data flow must happen instantaneously, must be delivered only
once, and delivery must be guarenteed, you have many more complications in
systems that support such needs.
If you design your data flows to be auditable (sequencing or time based
delivery), accept "at least once" delivery semantics (because you can audit the
delivery for duplicates), and provide "resend when missing" operations from the
source, then you can build much cheaper solutions with a lot less hardware.
This means that a restarted javaspace doesn't need to worry about being out of
sync with the world. It would make available any data that was persistent from
the last run, and it would not care about the state of any other instances
associated with the "cluster."
Many systems don't have such nice features built in. Sometimes I hear people
say "we don't need sequence numbers." They add that "the system guarentees
sequencing for us". It's because systems try real hard to be perfect that
people come to expect perfection and demand expensive solutions to get it.
The petroleum products industry has a lot of experience in making important data
flow over fragile communications infrastructure. Their main point of
maintaining consistency is to have keysets comprised of
"source,time,sequence"
Its impossible for duplicates to arrive based on this keyset. And, because
sequence numbers are created at the source (the meters), and are guarenteed to
be sequential with no missing entries, you can audit with a simple sort on
source,time to find that you are missing data and to then rerequest it.
These kinds of systems require much less complexity than systems without such
features.
Gregg Wonderly
===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS". For general help, send email to
[email protected] and include in the body of the message "help".
To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html