Intermittent Lazy Load failure

[Daryl Stultz]

Hi Rob,

We've got a highly-used query that has some intermittent failures. The query is raw sql (RawSqlBuilder.unparsed()) and the parent (ScheduledAssignment) has a member Role which is a single-table-inheritance class. I'm on 4.1.8 so I can't map the discriminator column. I have a FetchConfig.query() to preload the Roles (which suffers a bit since the foreign keys aren't loaded by the raw query, but it does work).

What does this traceback tell you?

javax.persistence.EntityNotFoundException: Bean has been deleted - lazy loading failed
        at com.avaje.ebean.bean.EntityBeanIntercept.loadBeanInternal(EntityBeanIntercept.java:723)
        at com.avaje.ebean.bean.EntityBeanIntercept.loadBean(EntityBeanIntercept.java:692)
        at com.avaje.ebean.bean.EntityBeanIntercept.preGetter(EntityBeanIntercept.java:779)
        at com.opentempo.webapp.modeleb.ScheduledAssignment._ebean_get_role(ScheduledAssignment.java:4)
        at com.opentempo.webapp.modeleb.ScheduledAssignment.getRole(ScheduledAssignment.java:183)

The obvious conclusion is that the row isn't in the database any more but we're pretty sure that's not the case. 

First question, does this exception suggest the ScheduledAssignment has been deleted or the Role has been deleted?

Second, if we are building the root with Raw SQL, and populating the Role with FetchConfig.query(), what are the circumstances that could lead to this exception?

Thanks.

/Daryl

[Daryl Stultz]

Hi Rob, not sure if you missed this one. Any thoughts?

[Rob Bygrave]

Honestly I haven't really looked at it (missed it).  How easily/quickly/frequently does the issue occur?

A thought that jumped out was around the Raw SQL. I was wondering if instead of RawSql a DB view could be created, based an new entity (for read only use) on the DB view and try that approach. 

... but I won't get to look at this in anger until late today.

Cheers, Rob.

--

---
You received this message because you are subscribed to the Google Groups "Ebean ORM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ebean+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daryl Stultz]

On Wed, Jan 20, 2016 at 2:36 PM, Rob Bygrave <robin....@gmail.com> wrote:

Honestly I haven't really looked at it (missed it).  How easily/quickly/frequently does the issue occur?

It's a very popular query, so it gets run a lot. It does not fail very often. It's hard to put any number to it. 

A thought that jumped out was around the Raw SQL. I was wondering if instead of RawSql a DB view could be created, based an new entity (for read only use) on the DB view and try that approach. 

Possibly, yes. I did have a unit test fail this morning on a lazy load on some other query (not a RawSqlBuilder query, though it did have raw sql in the criteria). I re ran the build and it passed. I'm wondering if there's any sort of weak reference code that lead to this? This is on 4.1.8.

but I won't get to look at this in anger until late today.

Well, I don't want to make you angry... :-) 

/Daryl 

[Rob Bygrave]

:) ... seriously it is always good to 'ping' on an email that didn't get a response because I do miss things and drop the ball etc - I'll not get into a "funk" for a 'ping' I promise :) !!

The only use of WeakReference in 4.x should be in AutoTune (collecting node usage statistics).  Yes, your memory is correct - there was a use of WeakReference in lazy loading back in 3.x which was refactored out in the later versions of 3.x.  In 4.x WeakReference should have no part to play here ... (if you get a chance to search the source to confirm that would be good).

Cheers, Rob.

--

[Rob Bygrave]

>>

What does this traceback tell you?

javax.persistence.EntityNotFoundException: Bean has been deleted - lazy loading failed
        at com.avaje.ebean.bean.EntityBeanIntercept.loadBeanInternal(EntityBeanIntercept.java:723)
        at com.avaje.ebean.bean.EntityBeanIntercept.loadBean(EntityBeanIntercept.java:692)
        at com.avaje.ebean.bean.EntityBeanIntercept.preGetter(EntityBeanIntercept.java:779)
        at com.opentempo.webapp.modeleb.ScheduledAssignment._ebean_get_role(ScheduledAssignment.java:4)
        at com.opentempo.webapp.modeleb.ScheduledAssignment.getRole(ScheduledAssignment.java:183)

The obvious conclusion is that the row isn't in the database any more but we're pretty sure that's not the case. 

First question, does this exception suggest the ScheduledAssignment has been deleted or the Role has been deleted?

<<

This is attempting to lazy load the ScheduledAssignment bean (triggered due to the role property not being loaded). This typically (I say typcially because we can also hit L2 cache here as well) queries against the DB and that should load the missing properties and set the lazyLoadProperty index to -1 indicating it all went as expected.

That lazyLoadProperty index is still apparently -1 and thus then implying that the bean was not loaded and implying that a matching row based on the primary key was not processed.

I'm still looking at this ...

[Rob Bygrave]

I have done some refactoring for #534 and found an issue #535.

As part of this I have improved the exception such that it includes the bean type and id. I'll send you a snapshot if you want to try that.

Cheers, Rob.

[Daryl Stultz]

On Thu, Jan 21, 2016 at 2:58 AM, Rob Bygrave <robin....@gmail.com> wrote:

I have done some refactoring for #534 and found an issue #535.

As part of this I have improved the exception such that it includes the bean type and id. I'll send you a snapshot if you want to try that.

Thanks, Rob, I think the new exception information will help. Because it's so rare to occur, I don't think the snapshot will be useful, but our upgrade to Ebean 6 is going well, so we should be able to get it in to our QA process in about 2 weeks. I imagine you'll have another minor release by then.

Thanks.

/Daryl

[Rob Bygrave]

Yes, we are almost releasing once a week at the moment. I expect the frequent releases to continue with the current setup so 2 weeks is good.

With the extra logging we can look into this issue better.

Cheers, Rob.

PS: I so totally missed that 'anger' joke the other day :)

[Daryl Stultz]

On Thu, Jan 21, 2016 at 2:57 PM, Rob Bygrave <robin....@gmail.com> wrote:

PS: I so totally missed that 'anger' joke the other day :)

I wasn't sure if maybe "I will look into it in anger..." was a local saying, meaning perhaps, "I will look in to it more aggressively", or as we might say "more earnestly".

/D

[Rob Bygrave]

Yes your interpretation was correct.  It might even be my own bit of colloquialism there ... 

We'd also say "Getting into in boots n all" ... so that is full commitment, getting in and sorting it out.

--