What does the "unowned side" part mean in the following?:
"3.16. Many-to-one
A many-to-one association is the most basic sort of association we can imagine. It maps completely naturally to a foreign key in the database. Almost all the associations in your domain model are going to be of this form.

Later, we’ll see how to map a many-to-one association to an association table.

The @ManyToOne annotation marks the "to one" side of the association, so a unidirectional many-to-one association looks like this:

class Book {
    @Id @GeneratedValue
    Long id;

    @ManyToOne(fetch=LAZY)
    Publisher publisher;

    ...
}
Here, the Book table has a foreign key column holding the identifier of the associated Publisher.

A very unfortunate misfeature of JPA is that @ManyToOne associations are fetched eagerly by default. This is almost never what we want. Almost all associations should be lazy. The only scenario in which fetch=EAGER makes sense is if we think there’s always a very high probability that the associated object will be found in the second-level cache. Whenever this isn’t the case, remember to explicitly specify fetch=LAZY.

Most of the time, we would like to be able to easily navigate our associations in both directions. We do need a way to get the Publisher of a given Book, but we would also like to be able to obtain all the Books belonging to a given publisher.

To make this association bidirectional, we need to add a collection-valued attribute to the Publisher class, and annotate it @OneToMany.

Hibernate needs to proxy unfetched associations at runtime. Therefore, the many-valued side must be declared using an interface type like Set or List, and never using a concrete type like HashSet or ArrayList.

To indicate clearly that this is a bidirectional association, and to reuse any mapping information already specified in the Book entity, we must use the mappedBy annotation member to refer back to Book.publisher.

@Entity
class Publisher {
    @Id @GeneratedValue
    Long id;

    @OneToMany(mappedBy="publisher")
    Set<Book> books;

    ...
}
The Publisher.books field is called the unowned side of the association.

Now, we passionately hate the stringly-typed mappedBy reference to the owning side of the association. Thankfully, the Metamodel Generator gives us a way to make it a bit more typesafe:

@OneToMany(mappedBy=Book_.PUBLISHER)  // get used to doing it this way!
Set<Book> books;
We’re going to use this approach for the rest of the Introduction.

To modify a bidirectional association, we must change the owning side.

Changes made to the unowned side of an association are never synchronized to the database. If we desire to change an association in the database, we must change it from the owning side. Here, we must set Book.publisher.

In fact, it’s often necessary to change both sides of a bidirectional association. For example, if the collection Publisher.books was stored in the second-level cache, we must also modify the collection, to ensure that the second-level cache remains synchronized with the database.

That said, it’s not a hard requirement to update the unowned side, at least if you’re sure you know what you’re doing.

In principle Hibernate does allow you to have a unidirectional one-to-many, that is, a @OneToMany with no matching @ManyToOne on the other side. In practice, this mapping is unnatural, and just doesn’t work very well. Avoid it.

Here we’ve used Set as the type of the collection, but Hibernate also allows the use of List or Collection here, with almost no difference in semantics. In particular, the List may not contain duplicate elements, and its order will not be persistent.

@OneToMany(mappedBy=Book_.PUBLISHER)
Collection<Book> books;
We’ll see how to map a collection with a persistent order much later.

Set, List, or Collection?
A one-to-many association mapped to a foreign key can never contain duplicate elements, so Set seems like the most semantically correct Java collection type to use here, and so that’s the conventional practice in the Hibernate community.

The catch associated with using a set is that we must carefully ensure that Book has a high-quality implementation of equals() and hashCode(). Now, that’s not necessarily a bad thing, since a quality equals() is independently useful.

But what if we used Collection or List instead? Then our code would be much less sensitive to how equals() and hashCode() were implemented.

In the past, we were perhaps too dogmatic in recommending the use of Set. Now? I guess we’re happy to let you guys decide. In hindsight, we could have done more to make clear that this was always a viable option."