Cleaning up after static member variables?

[Scott Harper]

I have a static member variable, in this particular case a Hibernate
SessionFactory. It is initialized in a static block. The
SessionFactory class has a close() method, which can free up resources
related to the factory...

How/where is the best place to call SessionFactory.close() on this
static object?

Or should I just not worry about calling close()?


scott

 

[Adam Maass]

I have a static member variable, in this particular case a Hibernate
SessionFactory. It is initialized in a static block. The
SessionFactory class has a close() method, which can free up resources
related to the factory...

How/where is the best place to call SessionFactory.close() on this
static object?

Or should I just not worry about calling close()?

You should call 'close' before the application shuts down.

How an application shuts down is highly dependant on the particular
application; some frameworks (IE, Servlet API) provide hooks into the
shutdown sequence. Others (IE, simple single-threaded application) are more
straightforward.

Furthermore, starting the SessionFactory should be done at startup time --
and in this case, it is, implicitly, via the static block. But IMHO,
non-trivial static blocks are huge code smells -- exception handling is
weird; you can get strange (and nearly inexplicable) NoClassDefFoundError s
if the static block throws an exception for any reason. And the blocks
generally run far earlier than I would expect, but also (paradoxically) far
later than is truly useful. So I'd suggest refactoring such that the startup
call is explicit -- and that might provide some clues as to how to get the
shutdown calls to the right object.


-- Adam Maass

 

[Roedy Green]

How/where is the best place to call SessionFactory.close() on this
static object?

Or should I just not worry about calling close()?

the problem is the class can always be used. There is no natural shut
down of a class. So it is up to you to call it when you are sure it
will never be used again.

Another possibility, perhaps not applicable in your case, is to use a
singleton, and recreate it later if needed.

 

[Owen Jacobson]

I have a static member variable, in this particular case a Hibernate
SessionFactory. It is initialized in a static block. The
SessionFactory class has a close() method, which can free up resources
related to the factory...

How/where is the best place to call SessionFactory.close() on this
static object?

Or should I just not worry about calling close()?

scott

Your problem is not "how do I clean up static crud when the app shuts
down". It's "how do I make the SessionFactory available to everyone
while still retaining control over it?". Making it static was, IMO,
the wrong decision, for reasons you just discovered.

Odds are good that only a handful of classes actually need the
SessionFactory, but they're annoyingly far from the ones main() calls
to do work. The main() method, either directly or indirectly, should
provide the SessionFactory directly to those classes (so you don't
have to pass it down through every class that uses the classes that
use the session factory to get it where it needs to go), and main()
should arrange for it to be closed at shutdown (either at the end of
main, for simple apps, or in the window event handlers leading to
shutdown, for GUI apps).

This is what dependency injection frameworks do for you; doing it
yourself is tedious but not hard.

 

[Sabine Dinis Blochberger]

You should call 'close' before the application shuts down.

How an application shuts down is highly dependant on the particular
application; some frameworks (IE, Servlet API) provide hooks into the
shutdown sequence. Others (IE, simple single-threaded application) are more
straightforward.

Seriously, does the following not work every time, depending on
framework?

Runtime.getRuntime().addShutdownHook( new Thread() {
public void run() { closeApp(); }});

Doesn't hurt to add it though.