Yeah, should have mentioned that avaje queries all the properties of the table at the moment.

> do these last lines of my autofetch log look strange to you?
Not really... the "setArt" property seems like an interesting property name ... I'm assuming that is that a valid property name on that bean (rather than a setter method name)?

> autoFetch honors the whole stack trace beginning at the first non-avaje one, no?
That's right... in v1.0.3 I did change the way Ebean finds the first non-avaje part of the stack... but looking at the hashcodes that does not look to be the problem (hashcodes are different).

No, nothing is really jumping out at me I'm afraid.

- Rob.

setArt is a propertyName, the setter then looks setSetArt ;-)

Hmmmm .... ok, I understand.

The above looks is the run 4 and 5 (I think) of the program.

If I understand the output correctly, then Avaje treated each run as NEW, and the hash code changes even if the stack trace should be the same.

Ok, I'll debug further into this. Shouldn't be too hard to nail down I hope.

Thanks!
Ciao,
Mario

update, the strack trace hash seems to be fine, but the queryPlanHash changes:

Here a simpler log of two runs, given the log, Avaje correctly determined the columns, but due to the queryPlanHash is not able to find it again.

"'10:44:06.220'","New","com.ops.Premium.model.po.Mdknd","-368625734:906546316","to: select (vorname, zuname, ort, plz, opsVersion) ","","com.ops.OPSJ.lib.model.PersistentObjectQuery.createList(PersistentObjectQuery.java:69)"
"'10:44:06.220'","New","com.ops.Premium.model.po.Mdknd","697279588:906546316","to: select (vorname, zuname, ort, plz, opsVersion) ","","com.ops.OPSJ.lib.model.PersistentObjectQuery.createList(PersistentObjectQuery.java:69)"
"'10:44:06.222'","Summary","new[2] modified[0] unchanged[0]",,,,
"'10:45:42.777'","New","com.ops.Premium.model.po.Mdknd","2018756749:906546316","to: select (vorname, zuname, ort, plz, opsVersion) ","","com.ops.OPSJ.lib.model.PersistentObjectQuery.createList(PersistentObjectQuery.java:69)"
"'10:45:42.777'","New","com.ops.Premium.model.po.Mdknd","-374717364:906546316","to: select (vorname, zuname, ort, plz, opsVersion) ","","com.ops.OPSJ.lib.model.PersistentObjectQuery.createList(PersistentObjectQuery.java:69)"
"'10:45:42.779'","Summary","new[2] modified[0] unchanged[2]",,,,

I'll analyze getQueryPlanHash(), probably something how I use the Query stuff.

The patch at BUG75 solves this, at least for my simple test class.

I still have problems with my main application, now avaje is not correctly gathering the access statistics ...

Note: it works with the simple test class.

A wild guess is that it has something to do with the fact that the query is executed in another thread than the one accessing the data then!?

Ok, got the last one too. Short story: It works!

Reason why it looked like it did not work is that I tested this stuff that way that I started the application, added something into a search field, waited for the response and exited the app.

Then the usage statistic was not correct, means, only the version column as been marked as used into the autofetch log.

When I did not immediately exited the app, but issued another query and then exited it worked.

What I have found is that in the first (fast) case the NodeUsageCollector.finalize() method is been called only once.

In the second (double search) case the NodeUsageCollector.finalize() method is called for each entity (I guess), but probably only those from the first query (?).

Now, that my List is "top heavy" (I traverse only the first few records) the NodeUsageCollector in the first case seems to be one of the bottom records.

Hmmm ... I ask myself how to fix this? Someone is holding a reference which prevents the garbage collector to correctly finalize all objects on shutdown.
I think it is not even guaranteed that each object gets .finalize() called, is it?

Ciao,
Mario

Think I got this one too. It seems you have to be VERY careful what to put into an Swing KeyListener, IMHO they are not released immediately if a "view" has been disposed.

However, I fixed (workaround) this for our application :-)

Now I see finalize gets called a the end of application.

This, and a patch like BUG75 - and I am happy again ;-)

Ciao,
Mario