Thanks for the replies. Below are my comments on the discussed topics
> Have you considered using an actual standalone caching product such as > Redis or MemCache as your cache rather than trying to create your own > synchronized distributed in-memory cache? That was the first thought but since we are trying to build a cache with activemq mainly because 1. We need this caching capability only for a couple of features in our application out of say 30 features it has. Adding another component in the architecture just for this doesn't sound worthwhile from an operations perspective 2. We already have activemq in our architecture hence we wanted to use if we can reuse that aspect. > If you use the TCP transport, it will stay connected continuously, and > then > disconnect if the broker goes down. If that happens, I believe an > exception > will be thrown the next time your code polls for new messages. If the exception gets thrown only when the subscriber polls then the cache could be stale. Is there something that notifies (through an exception?) when the broker goes down? > In general, the terms "atomic" and "distributed" are contradictory in most > situations. If the OP is using this as a cache (i.e. a place to hold the > results of operations that you would otherwise be able to compute on > demand, as a performance optimization), he will be fine, and atomicity > doesn't matter. If on the other hand the OP requires that the "cache" stay > fully in sync and it's not possible to compute the value in the case of a > cache miss, then that's a database not a cache. Our application has a OLTP use case. The objects that we want to cache are metadata objects of the application. They don't change frequently after the initial configuration. Hence the thought of having a replicated cache. I came across this discussion <http://activemq.2283324.n4.nabble.com/How-to-ensure-reliability-of-publish-subscribe-against-occassional-network-hiccup-td2354084.html> from the old threads which looked exactly similar to what I am trying to do. I can sequence the writes such that we first write to the database (RDBMS) and then publish it on JMS. If that fails we can rollback the database transaction. We look good on the publisher side. We can even guarantee that the subscribers receive the copy with CLIENT_ACKNOWLEDGE (activemq would retry till everyone reads the copy) but the two situations are something that I cannot find an answer to 1. How should our application handle a failure flow in which the publisher pushes a message on the topic successfully but activemq goes down before sending that message to any of the subscribers (assuming non-durable subscribers)? Is there a way the subscribers could know that activemq is down? If so, we could invalidate the whole cache. 2. Given these cache updates need to be published & subscribed in real time, what special handling should we do in cases the subscriber is busy (overloaded) and unable to read the message from the topic? Thanks! -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
