activemq-dev mailing list archives

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

    [ https://issues.apache.org/activemq/browse/AMQ-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39595
] 

Marcos Sanz commented on AMQ-1244:
----------------------------------

Our DBAs confirm that configuring the replication server to ignore the lock-table is a possible
workaround with our system. This might be manufacturer-dependent. Using a lock table in a
different logical database (not to be replicated) is another possible solution.

Wouldn't it though be easier and much more portable to actually insert a (dummy) row in the
lock-table as the inter-broker communication mechanism? This wouldn't require a transaction
to be kept open for the whole lifetime of the broker.

> 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