Proposed refactoring to allow alternative persistence mechanisms

["Fateev, Maxim" <fa...@amazon.com>]

	Hi,
	We were looking at alternate message persistence mechanisms that can co-exist in current ActiveMQ code base and we are thinking of a mechanism that is somewhat incompatible with the current MessageStore and PersistenceAdapter APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a change as the PersistenceAdapter and MessageStore interfaces are referenced directly by the RegionBroker and by both the Queue and Topic region implementations. Therefore, we are proposing a relatively small backwards compatible refactoring of the broker code that would eliminate all dependencies on the PersistenceAdapter and MessageStore interfaces from those classes that do not use them directly. This refactoring would also allow creation of a custom Destination implementation that may use an alternative persistence mechanism on a destination by destination basis (which is exactly what we need to do).
	The main idea behind the refactoring is to replace many references to PersistenceAdapter with a new interface: DestinationFactory:
	public abstract class DestinationFactory { 
	abstract public Destination createDestination(ConnectionContext context, ActiveMQDestination destination, DestinationStatistics destinationStatistics) throws Exception;
	abstract public Set getDestinations(); 
	abstract public SubscriptionInfo[] getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException; 
	abstract public long getLastMessageBrokerSequenceId() throws IOException; 
	abstract public void setRegionBroker(RegionBroker regionBroker); 
	} 
	Note that DestinationFactory doesn't mandate any specific persistence mechanism. The classes that would reference it instead of PersistenceAdapter are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the AbstractRegion.createDestination method would be changed from abstract to an implementation that uses DestinationFactory to create a destination.
	BrokerService could be changed to use DestinationFactory if one is provided. If none is provided, it will create a DestinationFactory implementation that instantiates Queue and Topic using PersistenceAdapter as it does currently. Hence, full backwards compatibility will be maintained.
	We have a preliminary implementation on local workspace. We can provide full patch for review. Appreciate your thoughts. 
	Thanks 
	Maxim Fateev.

Re: Proposed refactoring to allow alternative persistence mechanisms

[Hiram Chirino <hi...@hiramchirino.com>]

Please submit that patch!

On 8/10/06, Fateev, Maxim <fa...@amazon.com> wrote:
>         Hi,
>         We were looking at alternate message persistence mechanisms that can co-exist in current ActiveMQ code base and we are thinking of a mechanism that is somewhat incompatible with the current MessageStore and PersistenceAdapter APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a change as the PersistenceAdapter and MessageStore interfaces are referenced directly by the RegionBroker and by both the Queue and Topic region implementations. Therefore, we are proposing a relatively small backwards compatible refactoring of the broker code that would eliminate all dependencies on the PersistenceAdapter and MessageStore interfaces from those classes that do not use them directly. This refactoring would also allow creation of a custom Destination implementation that may use an alternative persistence mechanism on a destination by destination basis (which is exactly what we need to do).
>         The main idea behind the refactoring is to replace many references to PersistenceAdapter with a new interface: DestinationFactory:
>         public abstract class DestinationFactory {
>         abstract public Destination createDestination(ConnectionContext context, ActiveMQDestination destination, DestinationStatistics destinationStatistics) throws Exception;
>         abstract public Set getDestinations();
>         abstract public SubscriptionInfo[] getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
>         abstract public long getLastMessageBrokerSequenceId() throws IOException;
>         abstract public void setRegionBroker(RegionBroker regionBroker);
>         }
>         Note that DestinationFactory doesn't mandate any specific persistence mechanism. The classes that would reference it instead of PersistenceAdapter are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the AbstractRegion.createDestination method would be changed from abstract to an implementation that uses DestinationFactory to create a destination.
>         BrokerService could be changed to use DestinationFactory if one is provided. If none is provided, it will create a DestinationFactory implementation that instantiates Queue and Topic using PersistenceAdapter as it does currently. Hence, full backwards compatibility will be maintained.
>         We have a preliminary implementation on local workspace. We can provide full patch for review. Appreciate your thoughts.
>         Thanks
>         Maxim Fateev.
>
>
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com