activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcos Sanz (JIRA)" <>
Subject [jira] Commented: (AMQ-1244) DatabaseLocker implementation impedes database replication
Date Wed, 04 Jul 2007 08:58:34 GMT


Marcos Sanz commented on AMQ-1244:

I assume that the only communication channel that two brokers have in common is the database.
What about leveraging on the usual concept of a heartbeat? Let the Lock-Table have a datetime
row and let the active broker update periodically the row with the current (database) time.
If the standby broker detects that the row value diverges from the current time more than
a delta, then the active broker is stalled/dead. Advantages of this technique:
a) No transaction kept open for an undetermined time window
b) To my eyes, this is even more effective in detecting a failure that the current mechanism,
for it requires now the active broker to actually undertake an action,and not just remain
inactive holding a token.


> DatabaseLocker implementation impedes database replication
> ----------------------------------------------------------
>                 Key: AMQ-1244
>                 URL:
>             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:
> This command can only be executed within a transaction, see:
> 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.

View raw message