activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-1244) DatabaseLocker implementation impedes database replication
Date Tue, 03 Jul 2007 14:52:33 GMT

    [ 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.


Mime
View raw message