activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason R. Theune (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-1244) DatabaseLocker implementation impedes database replication
Date Thu, 19 Jun 2008 18:19:00 GMT

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

Jason R. Theune commented on AMQ-1244:
--------------------------------------

We have addressed an issue mentioned in TS-1244 with a snippet of code.
We would like to contribute our fix to the ActiveMQ 5.2 code base for consideration for permanent
inclusion.

This fix has proven out in our customer environment, and our customer is happy with the code.
We would now like to be sure our fix gets into the main branch so we do not have to patch
a one off version with every release.

Any chance in getting this patch accepted to the community through any channel that works?
 
The fix is fairly simple in that it basically does what James Strachan suggests in the ticket...
   (i.e., optionally use a different data source for the lock).  

This code change is submitted by Jason Theune on behalf of Rod Cope.

Here's the changed and added code in JDBCPersistenceAdapter.java:
 ======================================================
    // Added by Rod Cope of OpenLogic to allow the lock table to
    // reside in a separate database.  This makes sure that the
    // main database's transaction logs don't fill up because
    // the ActiveMQ lock transaction never closes.
    private DataSource lockDataSource;
 
    // Modified by Rod Cope of OpenLogic to allow the lock table to
    // reside in a separate database.  This makes sure that the
    // main database's transaction logs don't fill up because
    // the ActiveMQ lock transaction never closes. 
    protected DatabaseLocker createDatabaseLocker() throws IOException {
        return new DefaultDatabaseLocker(getLockDataSource(), getStatements());
    }

 
    // Added by Rod Cope of OpenLogic to allow the lock table to
    // reside in a separate database.  This makes sure that the
    // main database's transaction logs don't fill up because
    // the ActiveMQ lock transaction never closes.
    public DataSource getLockDataSource() throws IOException {
        if (lockDataSource == null) {
            lockDataSource = getDataSource();
            if (lockDataSource == null) {
                throw new IllegalArgumentException("No dataSource property has been configured");
            }
        } else {
            LOG.info("Using a separate dataSource for locking: " + lockDataSource);
        }
        return lockDataSource;
    }
    // Added by Rod Cope of OpenLogic to allow the lock table to
    // reside in a separate database.  This makes sure that the
    // main database's transaction logs don't fill up because
    // the ActiveMQ lock transaction never closes.
    public void setLockDataSource(DataSource dataSource) {
        this.lockDataSource = dataSource;
    }
 
Of course, it's fine if they resolve the issue in some other way that makes sense and/or change
any comments.  
I'd just like to avoid having our customer on a forked version because support efforts would
be complicated.


> 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
>             Fix For: 5.2.0
>
>
> 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