Introduction

In TensorFlow 1.x style code, global variable initialization belongs to the lifetime of a session and graph, not to the lifetime of an individual request. If you do not want to run global_variables_initializer() for every client interaction, the usual fix is to stop creating a fresh session per request and instead keep one initialized session or a serving process alive after startup.

Why Reinitializing Every Session Happens

A TensorFlow session starts with uninitialized variables unless you:

• initialize them in that session
• restore them from a checkpoint in that session
• reuse a session that already has initialized state

This means a pattern like this is expensive and wrong for a server:

with tf.compat.v1.Session() as sess:
    sess.run(tf.compat.v1.global_variables_initializer())
    result = sess.run(output_tensor, feed_dict={input_tensor: data})

If that block runs for every request, the graph state is rebuilt or reinitialized repeatedly.

Keep A Long-Lived Session Instead

A basic server-style approach is to build the graph once, create one session, initialize or restore variables once, and reuse that session for inference.

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5graph = tf.Graph()
6with graph.as_default():
7    x = tf.compat.v1.placeholder(tf.float32, shape=[None, 1], name="x")
8    w = tf.Variable([[2.0]], name="w")
9    y = tf.matmul(x, w, name="y")
10    init = tf.compat.v1.global_variables_initializer()
11
12sess = tf.compat.v1.Session(graph=graph)
13sess.run(init)
14
15
16def predict(values):
17    return sess.run(y, feed_dict={x: values})
18
19
20print(predict([[3.0], [4.0]]))

The key point is that sess persists across calls.

Restoring From A Checkpoint Is Usually Better Than Fresh Initialization

For trained models, you normally want checkpoint restoration rather than random initialization.

1saver = tf.compat.v1.train.Saver()
2
3sess = tf.compat.v1.Session(graph=graph)
4saver.restore(sess, "model.ckpt")

That loads learned variable values into the long-lived session once at startup.

Thread Safety Still Matters

A persistent session solves repeated initialization, but it introduces concurrency questions. If many requests hit the same session from multiple threads, you need a safe access strategy at the application layer.

The right design depends on whether the model is only serving inference, whether the graph mutates state, and how your web server handles parallel requests.

TensorFlow Serving Exists For This Problem

If the real goal is production inference, TensorFlow Serving or another dedicated model-serving layer is usually a better design than hand-managing one session in application code. A serving process keeps the model loaded and avoids per-request initialization overhead by design.

That is often the production answer even if a persistent session is enough for small internal tools.

TensorFlow 2.x Changes The Style

In TensorFlow 2.x eager mode, the language of "global variables per session" is much less central because ordinary Keras models and SavedModel exports are used more often than manual session management.

Still, the same architectural principle remains: do not reload or rebuild the model on every request if you want stable serving latency.

A Better Mental Model

Think in terms of process startup versus request handling.

At startup:

• build or load the model
• initialize or restore weights
• create any long-lived runtime objects

Per request:

• feed input
• run inference
• return output

Mixing those two phases is what causes repeated initialization pain.

Common Pitfalls

The biggest mistake is treating a TensorFlow session like a cheap per-request object. Another is re-running global_variables_initializer() after restoring a checkpoint, which can overwrite learned weights. Developers also sometimes keep a long-lived session but rebuild the graph for each request, which defeats the purpose. Finally, if you are already in a production-serving scenario, reinventing session management in app code can be more fragile than using a dedicated serving system.

Summary

• Variables are initialized or restored per session, so a new session per request causes repeated setup work.
• Keep one long-lived initialized session if you are serving from TensorFlow 1.x style code.
• For trained models, restore from checkpoints instead of reinitializing variables.
• Separate server startup work from request-time inference work.
• In production, a dedicated model-serving system is often better than manual session management.