I'm not sure what the best answer is. But essentially, my analysis boils
down to the fact that I could use the database identifier if I could get
it. But I can't get it when I need it (before assigning my object to a
set). So instead I have to use a business surrogate which uses an
immutable property. Most of my objects have almost entirely MUTABLE
properties, except for maybe the "created" date (as mentioned above).
But that still doesn't sit right in my stomach. I think the chance of an
inadvertent duplicate using "created" is too high.

So my solution. I created a uid field in my BasePersitentObject. its
setter is private (only to be used by Hibernate). its getter is
protected (though I could probably make it private too). It is assigned
when the object is created (new), and persisted with the object, so it
can be reloaded when objects are reloaded.

The uid function I use was posted on
http://www.javaexchange.com/aboutRandomGUID.html

The base class implements hashCode and equals, and though they are
public, I do not want any of my peristent objects to override them,
since I can't imagine that they will come up with a better immutable
hashCode/equals function.

The other advantage of this system is that when I load in data from my 
legacy system, I can make the uid = the id of the OLD data, since that
is guaranteed to be unique across a table.

That being said (and this seems to work well), this makes business
equivalence break for me. For example, if I have two last names, and a
LastName persistent object (which would never happen, but you get my
point), they should be equivalent if "Smith" and "Smith", but this would
make those not equal, which is correct. They are equivalent but not equal. 

Enough rambling...