On 1/28/08, glassfish_at_javadesktop.org <glassfish_at_javadesktop.org> wrote:
> >
> > Yes, this is exactly the kind of thing I was hoping
> > to find built in
> > to one of the many java dbs or JDBC proxies out there
> > :-)
>
> For a little while we were toying with the idea of using Shoal inside Derby for building a shared cache Derby cluster. Have not gotten around to do that yet.
h2 does something similar with JGroups. The data can be persisted to
files, which is something we need, but it can't handle recovery when
the nodes restart. I'd have to figure out which node contains the
latest resvision myself.
> Anyone in the community willing to jump in to contribute? This will help many users take advantage of such facilities.
I can not commit neither personal, nor corporate resources at this
time, but we might get back to it later this year. Derby mailing list?
> > I don't run the glassfish instances in cluster
> > though.
>
> Any reason why not? Its pretty straightforward with GlassFish.
Yes, it's great, but not what we need in this specific project:
We have two identical, but independent nodes doing the same thing,
trying to minimise error propagation. Same data is fed to both, same
results expected as output. Think avionics systems, but not as
critical.
Now the replicated database I'm asking about in this thread is just an
auxillary authorisation db, which we do have to share.
>
> If there is a specific reason for not having the instances as part of a cluster, then you could still use Shoal as long as your app makes the api calls to join and participate in a named group.
Didn't know that, thanks for the link too.
We have been trying to keep things container-agnostic, but that might
change down the road :-)
Gabor Szokoli