Let's say that I have one Database, and several separate web applications that share the database. If hashes are to be unique and generated on the server-side, how can I ensure that I am generating a unique hash across several applications?
Edit: for some reason, it seems that I have completely misread the question. The answer below applies to another question which has little semblance with the actual question.
As for your question, a simple way to ensure uniqueness (with high probability) is to use randomness: from a cryptographically strong PRNG, just produce 16 random bytes. That's 128 bits. Mathematics show that the first reuse happens once you have generated about 20 billions of billions of salt values, i.e. it won't happen soon.
The applications can also use a generation method which tries to achieve uniqueness by using the machine MAC address, the current time, the process ID and whatsnot. GUID are designed to do just that. Each server can simply request a "new GUID" when it needs a salt; a GUID encodes as 16 bytes. Indeed, one GUID generation method is to use a cryptographically strong PRNG, so both methods are actually the same.
Note that for a good salt, the uniqueness is supposed to be worldwide, i.e. to also apply for other applications which are connected to other databases, that you don't know of. Randomness and/or GUID take care of that, too.
Original answer which does not answer the question at all:
In password hashing, the salt is a "unique value": that is, each password gets its own salt value. A new salt is generated for each password. In particular, the salt MUST NOT depend on the password value (so it can not be "computed" from the password), and MUST NOT be used for more than one password (even if the same user just changes his own password, a new salt shall be generated).
Since the salt is necessary to recompute the hash, there is no escaping it: you must store the salt in the database along with the corresponding hash output. When the salt is stored with the hash value, whoever needs to validate a password first reads both the salt and the hash value from the database, then uses the salt and the password to recompute the hash value and see if it matches the one which was just read from the database.
Bcrypt implementations traditionally encode the salt and the hash output for you, as a single string, so you don't have to worry about two values to store: you store one string, you read one string, and the library does all the magic.
If the database is shared you should be able to query it before adding a hash. Add a unique constraint on the field containing the salt as this will prevent other apps reusing the salt. For salt generation refer to the bear.