| RE: [smila-dev] Sharing the same persistence storage (xmlstorage & binary) between different cluster nodes |
|
hi, if i may add my 2ct here: a) BDB Xml is cluster capable but u will always have just one
node being the write master while there are many read nodes. this has nothing to do with not putting ur DB files on a remote
FS as marius has written. there is also a PoC project around that has tested
replication with berkely. b) Because it is embedded we need to program the Xms Storage
Service such that it manages transparently which instance/node is the write
master and which instances just may read so the client doesn’t need to
know about this. i had to deferred this implementation until we know more about a) SCA/Tuscany, b/c SCA should give us transparency to remote
communication anyhow b) configuration management in a cluster, b/c that might have
direct impact on how we need to impl. the service. Kind
regards Thomas Menzel @ brox IT-Solutions GmbH From: smila-dev-bounces@xxxxxxxxxxx
[mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Marius Cimpean Hi, Here
are few remarks based on the discussion with Dmitry, who wanted to test
clustering scenario with multiple blackboards, when blackboards running on
separate nodes needs to share the same data (same persistence storage). Currently
no persistence service (xml and binary) support this test scenario (where the
stored data must be shared between separate cluster nodes). 1. Binary
Storage Service Through
the new concept of Binary storage it will be possible to achieve this feature,
by applying the appropriate configuration (http://wiki.eclipse.org/SMILA/Project_Concepts/Binary_Storage#Cluster_configuration -
page is under construction) 2. XmlStorage
Service The
Oracle Berkeley DB Xml does not support well remotely environment (it is an
embedded database architecture); The BDB Xml community discourage setting the
environment in remote file system. Also this depends on the operating system
where the environment is located. "When
Berkeley DB database environment shared memory regions are backed by the file
system, it is a common application error to create database environments backed
by remote file systems such as the Network File System (NFS), Windows network
shares (SMB/CIFS) or the Andrew File System (AFS). Remote filesystems rarely
support mapping files into process memory, and even more rarely support correct
semantics for mutexes if the mapping succeeds. For this reason, we recommend
database environment directories be created in a local filesystem." So,
it looks like for the remote situations, a number of constraints needs to
be met so the remote case work with BDB Xml environments. Based
on this, following solutions (for Oracle Berkeley DB Xml) are available in case
of node clusters needs to share the same XML persistence storage (BDB
Xml environment): 1.
at least we can try how the BDB Xml behaves in remote situations for SMILA (we
will need to test on different os) 2.
an extra layer needs to be developed in order to "fix" the
embedded database architecture and to solve the remote calls. This layer will
be located on the same node-machine as the BDB Xml environment, so the calls to
the BDB Xml native API are locally (this will make the
deploy/installation a bit complicated ...) Feedback
is very welcome. Best
Regards, Marius __________________________ Numerica
SA Phone
: +40 0364-101062 email
: marius.cimpean@xxxxxxxxxxx |