You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Dan Haywood (JIRA)" <ji...@apache.org> on 2018/08/31 22:05:00 UTC
[jira] [Updated] (ISIS-1976) Improve the metamodel cache management
[ https://issues.apache.org/jira/browse/ISIS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Haywood updated ISIS-1976:
------------------------------
Description:
The cache management we have with ObjectAdapter, might be simplified such that we just work with java.lang.Object so far as possible. We would have a "disposable" ObjectAdapter that we instantiate around an Object whenever we need it - to access into the metamodel - and then throw it away after. Or perhaps eventually we might not need ObjectAdapter at all, just simply use #getClass() to look up the ObjectSpecification.
~~~
The main objective is to get rid of these two maps:
[https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/OidAdapterHashMap.java]
and
[https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/PojoAdapterHashMap.java]
As their name suggests, these map:
oid -> adapter (look up an adapter from an oid)
pojo -> adapter (look up an adapter from a pojo)
The adapter itself has a reference to its oid (getOid()) and to its pojo (getObject()).
The "ensureMapsConsistent" method in PersistenceSessionXxx is there to ensure that these are maintained correctly; it's rather paranoid because if these get out of sync, then bad things would happen; eg:
[https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1184]
There's also some rather horrible "remapRecreatedPojo" methods that hack this stuff
[https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1739]
All this stuff is a legacy from the original client/server architecture that the framework used to have; it was probably needed then but I really don't think it's needed now.
~~~
At the moment the object adapters are created eagerly, typically using PersistenceSession#adapterFor(...). For domain services, we eagerly create an adapter around every service before each session, "just in case" it gets interacted with. This could be removed
[https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L237]
This also requires the ability to infer the Oid from the pojo, on the fly. There are two different ways this is done:
[https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/objectstore/jdo/datanucleus/persistence/spi/JdoObjectIdSerializer.java]
To do this for an domain entity (JdoIdHelper) vs for view models (RecreateableObjectFacet). Ideally the code to recreate/rehydrate the object should be more transparent
could perhaps provide a pluggable service so that can then support other persistence runtime stores ... the idea is that the framework encounters a pojo and then asks for a service (via an SPI) to see which can extract/infer an Oid from it, using the usual chain-of-responsibility pattern. Out-of-the-box the framework would provide two default implementations, one for DN entities (JdoIdHelper), the other for view models.
Ideally, PersistenceSession shouldn't need to use ObjectAdapter at all; the ObjectAdapter really exists only for the viewer(s) etc to obtain the ObjectSpecification to know how to render the object. Ultimately, we could get rid of ObjectAdapter completely and just uses pojos (=domain objects) everywhere. ObjectSpecification would remain, though. I think this is for other tickets, though, not this one.
was:The cache management we have with ObjectAdapter, might be simplified such that we just work with java.lang.Object so far as possible. We would have a "disposable" ObjectAdapter that we instantiate around an Object whenever we need it - to access into the metamodel - and then throw it away after. Or perhaps eventually we might not need ObjectAdapter at all, just simply use #getClass() to look up the ObjectSpecification.
> Improve the metamodel cache management
> --------------------------------------
>
> Key: ISIS-1976
> URL: https://issues.apache.org/jira/browse/ISIS-1976
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Reporter: Andi Huber
> Assignee: Andi Huber
> Priority: Major
> Fix For: 2.0.0-M2
>
>
> The cache management we have with ObjectAdapter, might be simplified such that we just work with java.lang.Object so far as possible. We would have a "disposable" ObjectAdapter that we instantiate around an Object whenever we need it - to access into the metamodel - and then throw it away after. Or perhaps eventually we might not need ObjectAdapter at all, just simply use #getClass() to look up the ObjectSpecification.
> ~~~
> The main objective is to get rid of these two maps:
> [https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/OidAdapterHashMap.java]
> and
> [https://github.com/apache/isis/blob/master/core/runtime/src/main/java/org/apache/isis/core/runtime/system/persistence/adaptermanager/PojoAdapterHashMap.java]
> As their name suggests, these map:
> oid -> adapter (look up an adapter from an oid)
> pojo -> adapter (look up an adapter from a pojo)
> The adapter itself has a reference to its oid (getOid()) and to its pojo (getObject()).
>
> The "ensureMapsConsistent" method in PersistenceSessionXxx is there to ensure that these are maintained correctly; it's rather paranoid because if these get out of sync, then bad things would happen; eg:
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1184]
> There's also some rather horrible "remapRecreatedPojo" methods that hack this stuff
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L1739]
>
> All this stuff is a legacy from the original client/server architecture that the framework used to have; it was probably needed then but I really don't think it's needed now.
> ~~~
> At the moment the object adapters are created eagerly, typically using PersistenceSession#adapterFor(...). For domain services, we eagerly create an adapter around every service before each session, "just in case" it gets interacted with. This could be removed
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/core/runtime/system/persistence/PersistenceSession4.java#L237]
>
> This also requires the ability to infer the Oid from the pojo, on the fly. There are two different ways this is done:
> [https://github.com/apache/isis/blob/master/core/plugins/jdo-datanucleus-4/src/main/java/org/apache/isis/objectstore/jdo/datanucleus/persistence/spi/JdoObjectIdSerializer.java]
>
> To do this for an domain entity (JdoIdHelper) vs for view models (RecreateableObjectFacet). Ideally the code to recreate/rehydrate the object should be more transparent
> could perhaps provide a pluggable service so that can then support other persistence runtime stores ... the idea is that the framework encounters a pojo and then asks for a service (via an SPI) to see which can extract/infer an Oid from it, using the usual chain-of-responsibility pattern. Out-of-the-box the framework would provide two default implementations, one for DN entities (JdoIdHelper), the other for view models.
>
>
> Ideally, PersistenceSession shouldn't need to use ObjectAdapter at all; the ObjectAdapter really exists only for the viewer(s) etc to obtain the ObjectSpecification to know how to render the object. Ultimately, we could get rid of ObjectAdapter completely and just uses pojos (=domain objects) everywhere. ObjectSpecification would remain, though. I think this is for other tickets, though, not this one.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)