Hi Emmanuel,
Thank you for your response.
Emmanuel Cecchet <[EMAIL PROTECTED]> wrote: Hi Chris,
> Is it possible to set up Sequoia embedded in a client application so
> that all the clients share the same data? I need to include new
> clients when they start up and safely allow clients to detach and shut
> down without data loss.
The problem is that all your clients would have to be able to connect to
the same group communication channel that will totally order all
messages. This is not really realistic in a WAN context, so all your
clients would have to be on the same local network.
Moreover, you'll need always at least one client to be up so that others
can synchronize against it, otherwise it's going to be a nightmare in
terms of management.
Thank you so much for the response - I am very encouraged about the project now.
My context is a softphone application that retrieves very little data from its
database (mostly configuration properties), and which will store a couple
hundred bytes of data for each phone call it handles (maybe 150 per person * 50
= 6,000 per 8 hrs). The scope crosses subnets, but doesn't extend into a WAN
(well, each site could have its own group that wouldn't overlap).
The driving factors for a distributed architecture are:
- users are hoteled, and may never sit at the same desk twice
- there is no access to a central database server, web server, or app server
- there is a file server from which the application will be launched
- I would like to allow users to manage the configuration & preferences
- I would like to "guess" user data from initial ID entry
- I would like to provide historical reporting per user
> The first issue I see is the static URL in the documentation, but I
> suppose I can create some kind of multicast message to acquire a
> cluster URL. (sort of an auto-discovery/zero-conf feature)
You don't need that, your application will always connect to the local
embedded database (so a local URL to the controller is fine). The real
auto-discovery thing will be handled by the group communication
membership service.
>From what I am beginning now to understand, this essentially entails that I
>distribute
- derby
- sequoia
- hedera (?)
- spread
with the application jar(s). I shall continue to learn
about Spread to see if the daemon processes they mention need to be set up as
services or can autostart with the application.
I am assuming there's docs on how to wire them up to each other - theoretically
the app may only need to know jdbc if the frameworks above all play nice
together... Are there special requirements to connect Sequoia with Hedera,
Hedera with Spread?
Here's a key question though: you said that one machine would have to be
always on. Isn't it more like there'd have to be one first machine and one
last machine? I imagine group activity to look like a game of life, sprouting
out of nowhere, growing, then diminishing, disappearing. The first machine to
attach gets to create the group; the last to detach shuts it down.
The only data which that last machine might write (and therefore need to sync
with the rest) might be a couple call history records and the logout time. I
don't foresee that becoming an issue, but if it is as you say we can specify
the solution would be that one machine stay on.
> I would really appreciate any thing you could do to help me focus on
> the relevant issues - should I even consider doing this?
It's hard to tell given the little context you gave but it could make
sense to use Sequoia more as a cache and use a remote database cluster for all
clients. Or maybe you just don't need a database and a
peer-to-peer technology could do the trick for you.
Thanks for your interest in Sequoia,
Emmanuel
On the contrary - thank you for Sequoia! I think it's the right solution - if
I've not included enough context above, please let me know the kinds of
information I should supply to help you help me.
Again, thank you so much for answering!
Chris
---------------------------------
Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings,
and more!_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
