1. Because embeddable object will always have an owning entity, it brings up a question whether query result should materialize the owning entity. Materializing owning entity has undesired side effects; if owning entity has any eager fields, additional SQL is generated which bring in data that is not requested by query.
if Person entity has an embeddable address field - "Address" is Embeddable class,
the following query returns Address objects of all Person:
select p.address from Person p
In processing the above query, Person should not be materialized, nor any eager fields/relations of Person.
For this reason, it is decided that if query is selecting embeddable objects, we only retrieve the primary key of the owning entity and save that owner id within the StateManagerImpl instance of the embeddable object.
2. Our current implementation that supports embeddable class is not OO style.
Strong-typing by introducing EmbeddedStateManager would be beneficial in the long run.
But this kind of structural change has big impact to kernal, cache, attach/detache, etc.