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 > > > >
