In general, globals are discouraged. But some things are really "global" in the sense that a single value or setting needs to be shared by many different pieces of code. Sometimes, as Karl points out, sharing data between different areas of your application can mean that your application is structured poorly. If you have 26 source files (named A-Z for simplicity) and 10 globals and 5 of those "globals" are used only by files C, H, and N, then you may want to look at C, H, and N to see what else they have in common and see if it makes sense to merge C, H, and N and make half of your former globals private.
On the other hand, some information may be truly global, like "application-name" or "is-whole-app-in-special-testing-mode." These things may be used in most files of your application. Some tests for good globals are:
Is the value immutable once it is set (good) or do you have to worry about one part of your application changing it at runtime and another part getting the old value by mistake (bad)?
Is it truly global - a single value that needs to be used by several different independent sections of your application? Obviously you want to eliminate unnecessary dependencies, but some dependencies are necessary.
Don't be an idiot. I've heard stories of people making "currently-logged-in-user" a global, thus limiting that web application to a single logged-in user. This kind of global is too stupid to be called evil, but it happens.
For example, when you say "session names" that could mean two things:
// Key used to look up number of items in individual user's shopping cart
// Each user's session has a hashtable of values and this is better than
// hard-coding the "numCartItems" string each time you use it because
// the compiler will catch a typo in the NUM_CART_ITEMS symbol, but not
// in a string:
String NUM_CART_ITEMS = "numCartItems";
// Stores number of items in individual user's shopping cart
// but puts everyone's items in the same cart - OOPS!
int NUM_CART_ITEMS = 0;