Re: question about persistence

Shay Hassidim wrote:
> Building clustered highly available JavaSpaces is not so simple.
>

Not entirely true.  Depends on exactly what you are trying to achieve
and at what cost.

You can build a simple highly available space with just a couple of bits
of hardware and a couple of software frameworks.  This won't be suitable
for all applications but might be for many.  For example, many telco's
use a simple master/slave failover pattern for various of their systems
because it's predictable, easy to debug and easy to maintain.

> We have invested and still investing great efforts building stable and
> reliable cluster aware JavaSpaces solution.
>
>
>
> There are many issues that need to be taken into account:
>

The below is true for a clustered space that you've chosen to implement
entirely in software and has multiple active instances at any one time.
  That's not the only way to build a cluster.

> - Data replication - There are synchronous/asynchronous replication issues
> that need to be resolved. Advanced applications would require reliable
> parallel multicast replication implementation to provide fast and optimized
> data replication. This involves heartbeat , handshake and other mechanisms
> that insure data coherency. You can't expect the OS or have some file to be
> used to sync the different spaces with the latest state - it is very costly
> and binds you to specific OS cluster technology. Replication should be done
> to entries data, lease info , take/read templates , notify templates and
> other space internal data.
>

This is true - it's made even more difficult by the visibility rules
required by the JavaSpace spec.  Potentially, many asynchronous update
algorithms would mean you weren't entirely compliant with the visibility
rules but you're probably sufficiently compliant for it not to matter.

> - Primary/backup space notion - the space need to be aware of other spaces
> running in order there would not be multiple primary active spaces. One of
> the most interesting problems here knows as the shot in the head approach.
>

Shooting in the head - that's actually a generic clustering issue.  It's
seen in all sorts of things including shared filesystems.

> - Transaction state - The source and target space might need to be aware the
> transaction state or at least throw exception when current primary space
> failed to allow the client to retry the operation.
>
> - Lease state - the space which took over need to maintain the entry lease
>
> - Notifications - the space which took over should start send notifications
> to clients
>
> - Silent failover - Connected users should move into the backup space
> silently. This means the client should have proxies to all relevant spaces
> to allow smooth fail in short time.
>

Well, maybe.  If you're programming to handle network failures anyways
(you're using Jini after all) this isn't actually necessary though I'd
agree it would be nice to have.

> - Recovery - when the original space restarted the current active space
> should sync its data with the restarted space. This means you need to build
> special king of iterator that will send the restarted space the active space
> data.
>
> - Persistency - if the space is persistent the durable storage (database)
> need to be re-sync when the original space restarted. This means the spaces
> should maintain both redo log and to do log to allow the restarted space to
> get only the changes since the time it failed from the active space and
> become available only when all data was fully recovered.
>

Hmmm, this feels like you're assuming a master/backup type model? There
are of course others based on gossip'ing and other lazy update modes
mixed with voting which would be implemented differently.

Best wishes,

Dan.

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