Re: question about persistence

Dan , Gregg ,

Thank you for your valuable inputs. I agree that clusters can be constructed
in various ways - the question is what is the quality of service provided
and the user requirements.



For the last few years most of our customers were looking for
memory/persistent , fast , reliable , easy to configure and stable cluster
that supports the items I listed in my original response. Remember that
GigaSpaces is used also as caching , messaging and collaboration middleware
where fast recovery is crucial. In addition, clustering is used to enable
scalability and not just for availability. So we had to support the most
demanding requirements with the highest quality of service exists - these
includes for example ability to replicate data to multiple spaces using
sophisticated synchronous reliable multicast mechanism we developed and
making sure data across the cluster will be 100% coherent. You can't expect
such data synchronization across the distributed spaces will be done through
3rd party product or via central database/shared disk. This is a core
component of our clustered JavaSpace implementation.



We do have customers with "simple" clustering requirements. Needless to say
these are fully provided as part of the product.



We would love to share with who ever interested our clustering capabilities
and our thoughts and plans regarding future clustering features. We might
come up with JavaSpaces cluster specification where all existing
implementations can benefit from. We can conduct it over a webex or at the
next Jini community meetings.



Regards,

Shay





-----Original Message-----
From: Gregg Wonderly [mailto:[email protected]]
Sent: Monday, April 24, 2006 11:12 PM
To: [email protected]
Subject: Re: question about persistence



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


===========================================================================
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