Type: New Feature
Affects Version/s: None
Fix Version/s: None
Currently a JPA provider cannot guarantee that Entities are serializable since it is always possible that the entity is pessimistically locked (select for update).
The other problem is that JPA entities (per spec) loose all the state of lazy loaded fields and their dirty tracking information on serialisation. The result is that you basically cannot use them for any web application. Even if most EE6 samples use entities directly in their backing beans this does not work in practice (if you do not use non-spec conform magic switches) if clustering kicks in or you use e.g. the JSF ViewMap to store your entities.
The JPA spec currently states that you can either use lazy loading or serialisation. But this is impracticable. Not being Serializable means that you cannot use Entities in a webapp. Not having LazyLoading means that you will end up with 'database spaghetti' (pulling one entity and materializing half the database).
A possible solution:
force that each @Entity produced via this OptimisticEntityManager must explicitly declare the following fields:
- @Id and @Version. Otherwise you cannot do optimistic locking properly after serialisation.
- a state field  to serialize all information needed to track dirty fields and lazy loading information even after serialisation.
 I'm not yet sure how to implement this best. OpenJPA and EclipseLink already store all the state in the enriched/enhanced/weaved entity. The problem is just that they need to be switched to a mode where they do not only serialize the native entity but also all additionally needed info as well.
Since Hibernate stores all this information in the EntityManager (and not in the Entity), we need to spare some field in the Entity which will get filled when the entity gets detached.
One way would be to introduce a new field of type javax.persistence.State which must always be available in Serializable entities used by an OptimisticEntityManager. Of course this field never gets persisted to the db.
Any other ideas and spec clarifications (if I misunderstood something) is highly welcome!