CODEWITHSUNDEEP
javaservertomcat7
Rob Bailey
Rob Bailey

Reputation: 1787

How to share static variable data across multiple instances of Tomcat?

My company has outgrown its single-instance Tomcat server and so needs to run multiple instances. However, in the code there are many static variables that keep track of various data including objects. (Sure, let the jabs and jeers begin.:) I have considered moving the static variables to be stored in Redis, but that could potentially be a lot of work. Is there an easier way to share mutable static-variable information across instances of Tomcat?

Update: per suggestion by @jake, a note on the nature of the variables. These variables mostly store aggregate information for the service as a whole, such as info on the users logged in within the past hour, various features accessed, etc.

Upvotes: 1

Views: 2426

Answers (3)

Jesfre
Jesfre

Reputation: 702

You are talking about to have a cluster. So you need a set of new paradigms. You can see this image as an example: Distributed system overview

Refer to this link to read more about clustering and load balancing.

Upvotes: 2

shanmuga
shanmuga

Reputation: 4499

You cannot do this as different tomcat instances are basically different process (possibly on different machines altogether) having separate heap space.
This is the same problem as storing session variables (Although Tomcat allows replicating session variable across instances) as you scale up replicating across instances becomes considerable overhead (and performance bottleneck).

So even if you could manage to replicate everything you are only delaying your problem for later and not solving it. For scaling any type server side storage is discouraged. If absolutely necessary distributed cache is the right direction. Or you could store everything in DB (added overhead of DB calls).

Reference
In Java, are static class members shared among programs?
session in cookis pattern

Upvotes: 0

Jake
Jake

Reputation: 9397

"[..] many static variables" keeping track of mutable information across the webapp sounds terrifying, frankly. If concurrency isn't being handled well, this is likely a source of all kinds of errors/problems. But more importantly even if concurrency is being done properly, that alone could be contributing to resource contention performance problems that are making your app outgrow its single-instance life. In this case even if you address the implementation by replacing with some type of more robust data store (which you probably should), the added network latency will likely exacerbate that problem substantially.

I would suggest reviewing what those variables are and determine if each of them really actually does need to be shared across the entire distributed application. If they turn out to be things that are just cached to avoid recalculations or re-fetching from a database, then maybe you can avoid putting those in a centralized datastore, and do something simpler like just putting them in application scope as @EJP recommended.

We'd need more specific use scenarios about some of those variables to make better recommendations.

Upvotes: 2

Related Questions