Ian,<br><br>I think the later is what's supported/implemented by BDB:<br><br>"Berkeley DB supports replication over multiple systems, enabling
applications to scale massively with low latency and provide fault
tolerance for high availability solutions. This technique works by
having all updates go to a designated master, which distributes changes
automatically to a set of replicas ..."<br><br><a href="http://www.oracle.com/technology/products/berkeley-db/db/index.html">http://www.oracle.com/technology/products/berkeley-db/db/index.html</a><br><br>I'm not sure at this stage if there are any changes required within Elephant itself as this may just be an "off-the-shelf" capability of the BDB backend.<br>
<br>Yarek<br><br><br><div class="gmail_quote">On Mon, Jan 5, 2009 at 6:19 AM, Ian Eslick <span dir="ltr"><<a href="mailto:eslick@media.mit.edu">eslick@media.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For kicks I spent a little bit of time thinking about what it would<br>
take to make Elephant work with BDB replication.  There is one thing I<br>
don't understand, if a client wants to initiate a write transaction on<br>
the master, does it have to be a completely application level process<br>
(for example, you have the execute-transaction function call run<br>
remotely) or can you do this at a lower level where you somehow<br>
forward the low level read/write log information from client to server<br>
to be committed?<br>
<br>
Ian<br>
<br>
_______________________________________________<br>
elephant-devel site list<br>
<a href="mailto:elephant-devel@common-lisp.net">elephant-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/mailman/listinfo/elephant-devel" target="_blank">http://common-lisp.net/mailman/listinfo/elephant-devel</a><br>
</blockquote></div><br>