Distributed OODBMS

Bruno wrote:
> anOmnniBase containerNew: 'Bank Instances' path:'\\MyHost\c:\omnibase\'.
This is exactly my problem - there is no shared filesystem between the
machines. There might (and for sure will) be firewalls between the
clients and the master. And I won't be able to convince the firewall
admins to allow smb over their firewalls - a simple tcp or udp service
is however possible.

> I do not know if it posible to you.
> You only needs a windows network.
No windows network :-(

CU,

Udo

Udo Schneider wrote:

> Good point ... I'd just have to make sure that there is some feedback
> from the clients to prevent the clients from not updating the db
> completely because one packet is missing.

I once worked with a nicely designed datafeed (from the London Stock Exchange,
in fact) which used broadcast updates to a number of clients.  If any client
missed an update, then it could request a re-transmission, which the main
server just inserted into its normal broadcast stream.  It was assumed that
such requests would be fairly rare, and that often, if one client couldn't
recieve an update correctly, then other clients would have had the same
problem.  Nice and simple, and it worked well.    In this case the server could
broadcast the contents of the file (as it grew) in order, but include
out-of-sequence blocks whenever requested.  I'd be included to include in each
block
    block number
    file ID
    current file size    // can change with each packet
    checksum
    <data>


> > Another point to consider is what happens when the DB is reorganised,
> > for instance garbage-collecting an OmniBase repository.  It may be that
> > the operation is (mostly) deterministic, so you could synch the clients
> > first, then compact each DB independently (then synch again), but it
> > might not be...
> I'd prefer to compact the db on the master only ... and then copy over
> to the client.

If the file is 4 GB before, and 2 GB after, then you may (depending on how
clever rsync is and how well it works with the OmniBase layout) end up sending
most of the 2 GB to all the clients, just to replicate information that they
already have.


In classical Prevalence Pattern, you don't look for "dirty" objects and log
their changing state.  You create (idempotent) Command objects which contain
all the data needed to perform an update, and log that (in some kind of
serialised form).  I.e.  if you are going to update the DB to change some
Person's #age, your serialised object would contain (say) the unique ID of the
person, the new age, and (perhaps implicitly) the information that this update
would change the indicated person's age.  In contrast, if you log the "dirty"
object's new state, then its the new instance of Person which would be written
to the change log.

The classical method avoids problems like the one you described, but does
require a specific way of coding, which might not be convenient, or might even
be impossible.

BTW, if there's a reasonable chance that clients will eventually want write
access to the database, then it would be worth thinking a little about how
whatever architecture you end up with will cope with that change.  For
instance, if you are doing file-level updates, then you'll probably have to
make all changes by sending them directly to the server, and letting the change
to the DB files trickle back to all the clients (including the initiating one).
Doing the distribution at the level of objects (or update commands) avoids that
problem since it can more easily be made symmetrical.

    -- chris