Transaction protocol

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Transaction protocol

Michał Ptaszek
Hi,

I need to manage transactions between two Erlang nodes connected by an IP network with firewalls and other network devices in the middle.
- I need to have the transaction parties state synchronised despite of network failure, any ideas about best standards for this?
- Has someone implemented or used a transaction protocol in Erlang, such as 2 phase commit, 3 phase comit or other?


thanks,
Eduardo Figoli
INSwitch Solutions





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20041104/c31dee4c/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Transaction protocol

Håkan Mattsson-6
On Thu, 4 Nov 2004, Inswitch Solutions - Erlang Evaluation wrote:

EF> I need to manage transactions between two Erlang nodes connected by an
EF> IP network with firewalls and other network devices in the middle.
EF> - I need to have the transaction parties state synchronised despite of
EF> network failure, any ideas about best standards for this?

There is no best all-purpose standard for this. It depends on what you
want to achieve and how much application specific knowledge you can
make use of. It is much simpler to implement specific recovery
protocols for a certain type of application than a generic one.

EF> - Has someone implemented or used a transaction protocol in Erlang,
EF> such as 2 phase commit, 3 phase comit or other?

Yes, both the 2 phase commit and the 3 phase commit (as well as a few
other) commit protocols are implemented i Mnesia. Take a look at
mnesia_tm:multi_commit/4.

Read also about the "lightweight" (2ph) and "heavyweight" (3ph)
transaction protocols in:

  http://www.erlang.org/~hakan/mnesia_internals_slides.pdf

The hard part is not the implementation of the commit protocol, it is
the recovery of the persistent data when the nodes are re-connected.

/H?kan



Reply | Threaded
Open this post in threaded view
|

Transaction protocol

Sean Hinde-2

On 9 Nov 2004, at 15:53, Hakan Mattsson wrote:

> On Thu, 4 Nov 2004, Inswitch Solutions - Erlang Evaluation wrote:
>
> The hard part is not the implementation of the commit protocol, it is
> the recovery of the persistent data when the nodes are re-connected.
>

Maybe it is time to re-evaluate the decision to never attempt to merge
updates after a partition in Mnesia. This could take the form of a
table property that declares hat this table is safe to merge on
re-connect and that some small errors due to time differences between
machines are acceptable.

The current assumption that all tables must return to a consistent
state by copying everything starts to fall down when we get to very
large tables (ref Per Bergquist talk at EUC as well as our own
experience).

If both nodes have free run for a significant time then currently all
updates on one node will be lost - in many cases this is worse than
potentially losing some consistency between multiple tables updated in
one transaction, and in many other cases (simple updates to single
tables) there would be no loss of consistency,  and much less loss of
updates.

Sean



Reply | Threaded
Open this post in threaded view
|

Transaction protocol

Hal Snyder-2
Sean Hinde <sean.hinde> writes:
...

> Maybe it is time to re-evaluate the decision to never attempt to
> merge updates after a partition in Mnesia. This could take the form
> of a table property that declares hat this table is safe to merge on
> re-connect and that some small errors due to time differences
> between machines are acceptable.

What is done with other large distributed database technologies? What
to do after partitioning is a requirements problem for any replicating
store, not just mnesia.

We know there is no single solution - it depends on the application
(as Lennart pointed out when he was consulting here). Not being a DB
expert, I wonder how the issue is handled with other replicating
databases.