I wouldn't say it's atomic, it just shifts around some of the error cases (you risk reading uncommitted writes that might be rolled back, instead of risking having a cache miss when a value should exist).
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. On reflection, I believe that the OP is looking for a database here, and that using a SQL-based database that supports XA transactions might allow him to support committing or rolling back the real-work transaction if the write to the "cache" database fails. So I retract my earlier suggestion to use a standalone cache, and instead I recommend using a standalone RDBMS that supports XA transactions. Tim On Tue, Apr 17, 2018, 10:50 AM Michael André Pearce < michael.andre.pea...@me.com> wrote: > 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 > >> > >>> > >> >
