Blog Projects
Escape Keys
A ColdFusion and Web Development Blog by Tom de Manincor
 

A number of requests and inquiries have come in about TransferSync and multiple application instances running on the same server.

Thanks goes to Dylan Miyake, who was kind enough to provide the solution.

I have updated the project TransferSync @ RIAforge, you can get the latest code there.

Major updates have been made to TransferSync.

This version has a critical fix for those dealing with related objects. Somehow, the afterCreate event was overlooked during the early conception of this approach for managing the Transfer cache using a JMS gateway.

Once, that was implemented, it was apparent that better synchronization for parent objects was needed. For instance, when a new child is created, or existing child has a parent switched during an update.

I have temporarily removed the sample app. Once I get a chance to clean it up, I'll bring it back. If you need samples, contact me.

Other then that, there have been some great improvements. Take a look at the change log, or grab the latest version here: TransferSync @ RIAForge

0.5 -CHANGE LOG- 3/9/2009
- enhancement - added observer toggle no longer dependent on lazy init
- enhancement - added debug toggle
- enhancement - added class filtering
- enhancement - added caching for parents
- enhancement - added getMemento and getVersion
- enhancement - more robust logging
- enhancement - coldbox versions supports pre-cf8
- fix - added support for after create events
- fix - added support for notifying parent classes

Here is a great post by Brian Ghidinelli on how to integrate TransferSync in a ModelGlue and Coldspring system.

Check it out: Synchronizing Transfer ORM in a Model-Glue/Coldspring cluster with TransferSync

A minor update with a major fix.

0.4 -CHANGE LOG- 11/13/2008 - enhancement - logging improvements and toggle setting/property added - enhancement - improved caching - enhancement - added getKeyMap method - enhancement - added argument to definition file - enhancement - changed definition file extension to .transfer - fix - added double lock to prevent concurrency issues with duplicate method creation

And for those using Coldbox there is an optimized version of the gateway in the package.

Grab a copy at: TransferSync @ riaForge

TransferSync v0.3 released.

If you don't know, TransferSync is a JMS gateway that keeps Transfer's cache synchronized across a cluster. It is delivered in a sample app to help you diagnose and get setup quickly.

I have just posted a quick update to the TransferSync project. There have been a couple fixes and some minor enhancement. Thanks to some great suggestions by Brian Ghidinelli.

Error trapping has been added if the gateway is down or an error occurs while sending a message. Additional properties have been added to the gateway class to make it more generic. Logging was updated to allow for better debugging, as well.

You can grab the latest version from TransferSync @ RIAForge.

The second release of TransferSync, didn't see any bug fixes. Instead, this edition includes some optimizations for those using Coldbox. There are no major changes to the methodology or function. Everything works the same. However, a few things have been updated to take advantage of the Coldbox cache and features to provide better performance.

Grab the latest version at RIAForge.org

Transfer has become almost a necessity for me these days. I recently had to deploy it on a clustered environment, and had to find a way to keep the Transfer cache between nodes in sync.

A centralized caching system like memcache would work, but a lot of refactoring would be required. Not to mention, Transfer's cache is its claim to fame.

I turned to google, and it led me to Sean Corfield's Blog. Where I found a number of good posts on the issue. Even some code that would do most of the dirty work for me. Score!

Almost...It didn't support composite keys. After I went at that, I decided to change the approach from requiring 2 gateways to just 1, and instead of 1 CFC to act as an observer and a gateway, I split them up.

The gateway gets set up in the CF Administrator. A config file is provided, and doesn't require any modification to get you going. Once it's running the JMS acknowledges it as a listener.

The observer gets attached to Transfer. It will trigger a method that sends a message to the JMS. The message carries the Transfer Object Class name and the ID of the Object that was either deleted or updated.

The JMS then brokers the message to all listening nodes.

That's right, there is a catch. It requires an instance of Active MQ JMS Message Broker, on each node That's an opensource Java Messaging Service by the Apache foundation. It's fairly light, taking up around 2MB RAM, and minimal CPU when at work. Not to mention, it's default installation will get you going instantly. The best part is the auto discovery that will detect other brokers on the same network. This frees you from having to maintain the config files for the CF gateway. No need to keep an up-to-date list of IPs for the nodes. You can deploy the gateway as-is to all nodes, and let ActiveMQ do it's thing.

The project is on RIAForge. I've included a sample app along with the code, for a couple reasons. If you are new to all this, then I suggest installing ActiveMQ, and using the sample app to verify everything is setup correctly. The other reason, is to provide sample code to speed up integration.