[JPA_SPEC-21] enable Serialisation of Entities Created: 10/May/12 Updated: 05/Apr/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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:
 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.
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!
|Comment by mkeith [ 15/May/12 ]|
We have actually spent a great of time discussing variants of this problem since the first release of JPA, and there are a few possible solutions to the problem, but because of differing vendor opinions, implementations, and philosophies we have not yet reached a satisfactory conclusion. Unfortunately it is doubtful we will be able to do so in this release, either.
|Comment by Mark Struberg [ 20/May/12 ]|
Thanks for the honest answer. As I am EG member on other JSR myself, I certainly know those 'games'. This special issue has indeed a long history. I've seen EJB bug reports from 2005 (or even older?) which are originated in this very problem. And they all got bulk-updated and set to closed WITHOUT solving the underlying problem.
But all this doesn't change the fact that this is still broken and users don't care about political games behind the scene. This is really one of the reasons why user turn away from JPA and use SpringData, iBatis and eBean instead.
Currently the only way you can work with JPA in big projects is the old EJB transaction pattern where all entities get detached after the service invocation and NOT get used anymore in JSF pages or even JSF backing beans. But exactly that is what most EE6 samples currently showcase - despite being broken. This also renders JSR-303 mostly useless. Really, the only way to use JPA in a web app atm is to only use DAOs in the view layer and doing optimistic locking detects manually. This just sucks.
As for the JPA vendors:
Are there any other JPA vendors which are active in the JSR or have a bigger community?
|Comment by ldemichiel [ 22/Feb/13 ]|
Well, we tried to resolve this via a proposal based on entity graphs, but could not achieve closure. This is something that we should revisit in JPA.next.