How to Handle Partially Loaded Bean after Serialisation

[raphaelNguyen]

Hi @rbygrave @rob-bygrave ,

I have a use case I hope you could give me some guidance with. My use case is:

• I do not register my Database on creation because I already use injection to manage these instances.
• I have a piece of code that load beans from the database, some of these beans are not fully loaded. This bean is then serialised to be stored somewhere and then deserialised and used by another part of the code.
• When the deserialised beans are used and lazyloading is triggered (when hitting a property marked for lazyloading), I get a PersistenceException in InterceptReadWrite.loadBean because beanLoader is null and I have no database registered.
• When using these objects without serialisation/deserialisation, it seems that things worked because beanLoader is present. However, being a transient field, beanLoader did not survive the serialisation/deserialisation.

Can I please ask what is ebean guidelines in handling situations such as this?

• Is partial object loading not supported across serialisation/deserialisation unless I have my databases registered? As I understand it, if I manage my own Database instances via injection, there is no need to register but I might have been mistaken here.
• On the other hand, since I've opted to manage my own Database instances, is there some steps I'm missing to restore the beanLoader property upon deserialising the bean?

Thank you very much for your time and assistance.

[rbygrave]

is there some steps I'm missing to restore the beanLoader property upon deserialising the bean?

There is API to set the BeanLoader. I believe for this case the app will need to explicitly set the BeanLoader after deserialisation.

[raphaelNguyen]

Thanks for your reply, @rbygrave.

To clarify your answer, I assume I would want to call EntityBeanIntercept.setBeanLoader using the BeanLoader returned by SpiServer.beanLoader on deserialisation.

[rbygrave]

Yes so:

BeanLoader singleBeanLoader = database.plugin().beanLoader();
...
entityBeanIntercept.setBeanLoader(singleBeanLoader);

Noting that if this is used it will lazy load a single entity bean rather than "batch" lazy loading. So if we do this too much we will see N+1 type lazy loading.

[raphaelNguyen]

Thanks, @rbygrave. I've noticed this is exactly what the registered database path in InterceptReadWrite.loadBean(int) is doing so between registering the database to get it to work and setting the bean loader myself upon deserialisation, there would be no difference. This is the main immediate consideration for me.

To completely avoid N+1 lazy loading, I would probably have to rethink the way I do things completely. I'll take your warning to heart and ponder this further.

[raphaelNguyen]

An additional question if I may. Do you know if there are other situations similar to this where the underlying ebean process try to default to the registered databases that I need to watch out for? This is given that

• my code does not interact with the utility static methods in io.ebean.DB
• my beans do not inherit from io.ebean.Model
• all my database interactions (e.g. reference, refresh) are done from my injected Database instances

I have been reviewing usages of the functionalities that retrieves the registered database(s) in io.ebean.DbContext and io.ebean.DB in the ebean code base to try to identify potential issues like this one but I thought I would ask the question in case you know of any such situations I might have missed.

Thank you very much for your help.

[rbygrave]

underlying ebean process try to default to the registered databases that I need to watch out for?

I believe that is it. With Query beans they can take io.ebean.Database explicitly, so I think we are left with dealing with the serialisation/deserialisation case.

[rbygrave]

As I see it the ideal is that entity beans that we use serialisation/deserialisation are actually fully read only and immutable and we are working towards this with Ebean. You may note we have InterceptReadOnly and InterceptReadWrite. This is potentially a slightly different use case from what you have but as I see it, it is the main use case wrt use of serialisation/deserialisation which we might summarise as a ...

"Application Cache of entity bean graphs that are Immutable and Read Only"

These are graphs in that they can include related entities via *ToOne and *ToMany.
These are Immutable in that we make mutation an Exception.
These are Immutable in that we do NOT allow further lazy loading.

Perhaps the thing of note here is that the existing L2 cache works on a "data basis" caching the underlying data, and this "Application Cache" will actually work on a entity bean graph basis / actual entity beans (and we want to support serialisation/deserialisation for this application cache).

I'd be keen to hear about your use case for serialisation/deserialisation. I'd be interested to know if it has overlap with the "Application Cache" concept that is work-in-progress.

Edit: As I see it, if we do this "Application Cache" well then for many folks it could replace the use of the existing L2 cache mechanism. To some extent it will be simpler but with strong requirements for being Immutable and Read-Only (unlike the L2 cache which does not have those limitations).