[
https://issues.apache.org/activemq/browse/AMQ-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39599
]
James Strachan commented on AMQ-1244:
-------------------------------------
The idea of keeping the transaction open is to keep a lock; so that if the
connection/transaction fails, the broker stops being the master, then all the
brokers fight to get the lock again.
Inserting a row in a database doesn't really help; if the master dies; how do
the slaves know?
If you can come up with a workable alternative I'm all ears. (Especially if its
with [a patch|http://activemq.apache.org/contributing.html] :) but until then,
I think the long transaction is the only real alternative we have.
You could experiement with the SQL (the Statements class) so that the lock
table is named to be in a different logical database; yet using the same
DataSource .
> DatabaseLocker implementation impedes database replication
> ----------------------------------------------------------
>
> Key: AMQ-1244
> URL: https://issues.apache.org/activemq/browse/AMQ-1244
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
> Affects Versions: 4.1.1
> Environment: Latest ActiveMQ snapshot, Sybase ASE 12.5.x
> Reporter: Marcos Sanz
> Priority: Critical
>
> The current implementation of the JDBC Master/Slave feature makes one broker
> (the master) acquire a lock on a database object. In Sybase, this has been
> implemented with the command:
> LOCK TABLE foo IN EXCLUSIVE MODE
> This command can only be executed within a transaction, see:
> http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__BookTextView/54552;pt=54651
> This implies that for the whole lifespan of the ActiveMQ-process there is an
> open transaction in the RDBMS. This is a problem in a professional
> environment making use of a database replication server: The open transaction
> impedes that the transaction log in the active database is emptied, then the
> stable queue at the replication server won't be purged and will steadily grow
> up to infinitum. We have been able to observe this behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
