Wang, Gang commented on MNEMONIC-464:

Hi [~Tao Jie] , Thank you for the explanation of your business requirement.

In your case, the Object set of a should be cached to disk if using a 
traditional approach, so I think that it still needs the mapping from A 
instance to B instance and the Map<B_ID, B> would always be on the heap. 

Using durable solution, it will save the SerDe operations but still need 
something like Map<B_ID, B> since the B instance could not be referred 

My 2 cents, either way, looks not possible to avoid Map<B_ID, B>...

> Support normal java object field in durable type
> ------------------------------------------------
>                 Key: MNEMONIC-464
>                 URL: https://issues.apache.org/jira/browse/MNEMONIC-464
>             Project: Mnemonic
>          Issue Type: New Feature
>    Affects Versions: 0.11.0
>            Reporter: Tao Jie
>            Assignee: Tao Jie
>            Priority: Major
> Today, we define a durable type(eg: DurableA), we may define a normal object 
> field(B b). When we restore a DurableA object a(eg: we put a into a 
> DurableHashMap and get it from the map later), its reference of b would lost. 
> As discussed with [~qichfan] offline, one solution is that we maintain a 
> Map<B_ID, B> to keep the reference of B and have a B_ID(long type) field in 
> DurableA. Then we can find the object b from restored object A.
> We can do this in the Mnemonic framework, and add a new type (maybe 
> DurableReference?) to support this situation. like:
> {code}
> class DurableA {
>  @DurableGetter
>   public abstract DurableReference<B> getFieldB();
>   @DurableSetter
>   public abstract void setFieldB(DurableReference<B> b, boolean destroy) 
> }
> {code}
> Then we can get object b by
> {code}
> a.getFieldB().get()
> {code}
> Any thought?

This message was sent by Atlassian JIRA

Reply via email to