activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <>
Subject [jira] [Commented] (AMQ-4365) Allow the Lease Locker to be used with out a JDBCPersistenceAdapter - so it can be a broker lock
Date Wed, 04 Sep 2013 11:43:53 GMT


Gary Tully commented on AMQ-4365:

@Farhad, there should be a single broker lock or a single lock at the mKahaDb level - having
each of the nested kahadb instances use their own lock is broken for a few reasons. not least
that the instances are created on demand, so a slave could see none when it starts.
A single instance of the sharedfilelocker could work (one bean referenced by each instance)
b/c the file lock is acquired at the jvm level.
But master/slave mKahaDb needs a little bit of love atm. Making MultiKahaDB extend LockableServiceSupport
or making the Broker extend LockableServiceSupport would fix this. The nested kahadb elements
would then need useLock=false
> Allow the Lease Locker to be used with out a JDBCPersistenceAdapter - so it can be a
broker lock
> ------------------------------------------------------------------------------------------------
>                 Key: AMQ-4365
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Improvement
>    Affects Versions: 5.8.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.9.0
> The locker interface needs another configure option to provide a broker service, or needs
to be brokerService aware so that a locker can get identity and access to the io exception
> The lease database locker is dependent on the jdbc pa to get statements and data source.
It should be possible to configure these independently such that it can be used standalone
as a broker lock. So setters for each.
> This will help sort out some of the dependencies between broker and lock implementations.
also making it possible to use a lease lock with kahadb for example.
> some context:

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message