Apache Ignite (is ASF product in this space)
Saying that if you want to do this, and not have consistency issue, if you design it so you publish the change event into the topic first and your app (including the instance that produces) consumes the data to update their local cache . This way the update is atomic across all your nodes including the produce, then if it fails all caches won’t see the change including the local. > On 17 Apr 2018, at 17:40, Justin Bertram <jbert...@apache.org> wrote: > > I agree with Tim about using an existing cache implementation. It seems > like a lot of work to re-invent the wheel here. If you're looking for an > open-source, Java-based cache implementation which uses the ASL 2.0 (e.g. > similar to Apache ActiveMQ) checkout in Infinispan [1]. > > > Justin > > [1] http://infinispan.org/ > >> On Tue, Apr 17, 2018 at 8:34 AM, Tim Bain <tb...@alumni.duke.edu> wrote: >> >>> On Wed, Apr 11, 2018, 6:09 AM pragmaticjdev <amits...@gmail.com> wrote: >>> >>> We plan to use activemq to build a replicated cache in our distributed >>> system >>> consisting of multiple java applications. In this deployment, an update >> to >>> any of the objects being cached in the jvm memory of the app server acts >> as >>> a producer which pushes the pojo to the jms topic. All other app servers >>> subscribe to it and update the object that is cached by them. Here's a >>> quick >>> deployment screenshot with 2 app servers. In production we would have a >>> maximum of 5-7 such app servers. >>> >>> <http://activemq.2283324.n4.nabble.com/file/t378744/ActiveMQ_Oracle.png> >>> >> >> >> 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? It seems like that would simplify >> your task significantly and reduce the risk of bugs and the need for >> troubleshooting. Reusing an existing product is typically better than >> re-inventing the wheel... >> >> >> I would like to get suggestions on below queries >>> 1. Given this is a real time use case (caching) we would want any >>> updates >>> to be replicated to all other app servers as soon as possible. What >> broker >>> configurations should we consider to make sure that the messages are >>> delivered in real time in all possible flows? >>> >> >> >> The default settings should be fine. >> >> >> 2. Would it be good to maintain a continuous connection with the >>> activemq >>> server on each app server in order to invalidate the cache in case the >> app >>> server fails to connect to activemq? If so, how could it be implemented? >>> >> >> >> 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. >> >> >> 3. How do we handle failure scenarios when the producer fails to >>> push an >>> object to the topic (in which case we might have to rollback the database >>> transaction) or the consumer fails to receive the java object? >>> >> >> >> Is the work that leads to the message being published done in response to >> the consumption of a JMS message? If so, you can use an XA transaction to >> roll back your database commit if the send fails. But if you're not >> consuming a message at the time, I'm not sure that the built-in XA >> transactions are available to you. But I'm not an expert on transactions in >> a JMS context, so I could be mistaken about that. But you'd have to add >> special logic to remove the cache entry on transaction rollback. >> >> Again, I'd use a standalone cache for this rather than creating your own, >> if at all possible. >> >> Tim >> >>> >>
