SerializedObjects

The single biggest source of Toplink headaches is the SerializationBarrier: every call to an EJB crosses it twice, first on the call parameters, then on the return value.

Serialized objects lose their connection to TopLink; TopLink doesn't recognize them anymore, and won't "kick in" to load/store the serialized objects (which, as far as TopLink is concerned, are not persistent anymore). The simplest example of this is when a persistent object has a TopLink-managed collection of persistent objects. E.g. the catalog has a list of products; calling the session bean method =findCatalogById()= returns a =Catalog= instance, yet calling =getProducts()= on a serialized instance (client side) _does not return anything_, even if the catalog indeed has products.

To get the collection of products for a catalog, it must be primed on the server side, in the session bean method. The _Toplink-ism_ we use for this is to get the collection's size, which populates the collection. E.g.

public Catalog findCatalogWithProductsById(Integer catalogId)
{
  Catalog catalog = (Catalog) findObjectById(catalogId);

  if (catalog != null)
  {
    // populate the products
    catalog.getProducts().size(); // or .iterator()
  }

  return catalog;
}

This way the products are loaded in the catalog, and the serialized catalog will carry over its entire graph of objects, including the products. (NB: for simplicity's sake, this example ignores the performance issue of serializing potentially thousands of products back to the client.)

See also TopLinkTroubleshooting?, p. 152.