cancel
Showing results for 
Search instead for 
Did you mean: 

Alfresco and Managed Transactions

jean-rémyrevy
Champ in-the-making
Champ in-the-making
I am finishing a project, which is using only Alfresco DM, and where High Availabilty is really an important matter.

In order to configurer properly my JBoss server (5.1 EAP) and my MySQL instances (Master/Slave Replication), I want to specify to the datasource to use the second node as failover (at least !).

As per the documentation :
Automatic reconnect

WARNING: DO NOT ENABLE AUTO RECONNECT IF YOU ARE USING MANAGED TRANSACTIONS

The auto reconnect does not preserve transaction state in the database.

It is ok if you are ALWAYS using auto-commit=true.

I asked this Stack Overflow, thinking that was a general question : http://dba.stackexchange.com/questions/19453/jboss-dont-fail-over-mysql-slave-using-datasource, but I think knowledged of internal mechanisms of Alfresco could save me.

So : does Alfresco really use managed transactions ?
If it does, in wich cases or under which conditions ?
2 REPLIES 2

mrogers
Star Contributor
Star Contributor
What are "managed transactions" as opposed to other sorts of transactions?  Alfresco is not using EJB container managed transactions if that's what it means.  Or Global distributed transactions which is the other term I've seen.

Equally alfresco does not run with auto commit = true

All Alfresco's transactions are wrapped in retrying transaction code due to the optimistic locking pattern used.  But transactions will not be retried after a database connection failure.

jean-rémyrevy
Champ in-the-making
Champ in-the-making
First, thanks for you quick reply Smiley Happy.

As far as I know, JBoss Managed Transaction are powered by JBoss TX architecture, that's to say support of Java Transaction API. Indeed that do is (simple) transactions.

You said
Equally alfresco does not run with auto commit = true
Do you mean that Alfresco in configured with auto commit = false ? Or do you mean that it really will not support auto-commit= true (that is what I understand and what I was believing).

The retry on the other node is a built-in facility of the MySQL ConnectorJ Driver(once again, for all I know), and I'm just about sure that this can't respect ACID prorperties :

Failover Support

MySQL Connector/J has failover support. This enables the driver to fail over to any number of slave hosts and still perform read-only queries. Failover only happens when the connection is in an autoCommit(true) state, because failover cannot happen reliably when a transaction is in progress. Most application servers and connection pools set autoCommit to true at the end of every transaction/connection use.

The failover functionality has the following behavior:

    If the URL property autoReconnect is false: Failover only happens at connection initialization, and failback occurs when the driver determines that the first host has become available again.

    If the URL property autoReconnect is true: Failover happens when the driver determines that the connection has failed (checked before every query), and falls back to the first host when it determines that the host has become available again (after queriesBeforeRetryMaster queries have been issued).

In either case, whenever you are connected to a “failed-over” server, the connection is set to read-only state, so queries that attempt to modify data will throw exceptions (the query will never be processed by the MySQL server).

Source : http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-configuration-properties.html