| AW: [smila-dev] Sharing the same persistence storage (xmlstorage &binary) between different cluster nodes |
|
Hi Thomas, I have some questions here: If BDB XML can have several process instances that operate on
the same data (wherever it is stored), but only one instance can have write
access to it, what happens if this one particular BDB (XML storage service) instance
is no longer available? Is there some kind of automatic role takeover by other (still
operating) instances? If not, than we have a single point of failure here L Furthermore, even if there is some kind of role takeover, how
should a client – in our case the blackboard service – know which
XML storage service instance has to call for writing the data? You do not really expect that the binding layer (realized e.g. via
SCA/Tuscany) should detect the call-type and (dynamically) forward it to appropriate
(writing) instance, do you? If I have misunderstood you in any point, than please create a wiki
page with a sketch and description of your idea so that we can have a solid base
for our discussion. Regards Igor Von: smila-dev-bounces@xxxxxxxxxxx
[mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Thomas Menzel 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 |