activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan (JIRA)" <>
Subject [jira] Commented: (AMQ-1244) DatabaseLocker implementation impedes database replication
Date Tue, 12 Jun 2007 08:26:33 GMT


James Strachan commented on AMQ-1244:

A few thoughts. Firstly note that this locking transaction never updates any data and never
needs to be replicated.

Couldn't the replication server just ignore the lock table? Or we could allow the lock table
to be in a different schema (logical database) if that helps?

There needs to be some table used for locking; as we need to ensure multiple brokers don't
write to the same logical database. Though by all means suggest a suitable workaround that
works for you with database replication; would ignoring the table, or moving it to a separate
logical database/schema work?

Worst case scenario; we could use a completely separate database entirely (even a different
JDBC provider! :) but I'd rather reuse the same DataSource if we can (it makes things much
simpler to code and removes a multitude of possible issues such as folks using a local Derby
DB for the lock :)

> 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