Hello,

Firstly, apologies for the duplication - I was originally posting to Hibernate Users and have just realised that was probably the wrong forum for this problem (http://forum.hibernate.org/viewtopic.php?t=974543), so I'm re-posting here...


Hibernate version: 3.2.2
Hibernate Annotations version: 3.3.0.GA
Hibernate EntityManager version: 3.3.0.GA
Database: MySql 5.0.27
JRE: 1.5.0_07 (Java HotSpot(TM) Server VM (build 1.5.0_07-87, mixed mode))


I'm having a problem loading objects where an inheritance hierarchy is involved. I have three entity types:

PlayerAccount
WalletPlayerAccount extends PlayerAccount
InternalPlayerAccount extends WalletPlayerAccount

None of these are abstract - an entity can be one of any of these three types.

The ORM specifies a Joined inheritance strategy:




I have two accounts in the database:

Account with ID 1 is an InternalPlayerAccount (i.e. there is a row in each of the tables PlayerAccount, WalletPlayerAccount and InternalPlayerAccount, all of which have id=1).

Account with ID 2 is a WalletPlayerAccount (i.e. there is a row in each of the tables PlayerAccount and WalletPlayerAccount which both have id=2, but no row exists in InternalPlayerAccount with this id).

Note that both these accounts have been created via Hibernate (i.e. via instantiation of new objects and then calling EntityManager.persist()) - they do not exist as a result of dodgy hacking direct to database, so I'm sure there isn't a data bug.

Now, if I start my application and invoke some tests that cause repeated loading of the account with ID=1 then it always comes back correctly as an InternalPlayerAccount.

If I then invoke a test that causes the loading of the account with ID=2 then it comes back correctly as a WalletPlayerAccount.

So far so good. Now, if I try to reload the account with ID=1 it comes back as a WalletPlayerAccount, not an InternalPlayerAccount. I can check the database and nothing has changed between the finds. Furthermore if I restart the application then the account is loaded as an InternalPlayerAccount again (until I load a WalletPlayerAccount that is, when the problem resurfaces again).

I can't understand what I'm doing wrong, especially as the entity with ID=1 loads properly until the object with ID=2 is first loaded. I have deliberately missed out a few things from the code above which I don't believe are relevant, but will happily be more verbose if anyone wants more info.

Many thanks
Darren


...followup post...


I'm still investigating this and have some more diagnostics.

Firstly, when performing the eager find that's causing the problem, I was using a named-query that performed LEFT JOIN FETCHes for PlayerAccount's lazy relationships and then calling Hibernate.initialize() to load the subclass lazy relationships. I've replaced the named-query execution with an EntityManager.find( Class, id ) (again followed by a bunch of Hibernate.initialize() calls where necessary) to see if that was causing the problem, but it has made no difference.

So, I inspected the SQL that Hibernate generates and found there is no difference between the SQL generated on the first call (which succeeds) and the last call (which returns the wrong type). For reference, here it is:




Next, I stepped through in the debugger...

1) the first find (an InternalPlayerAccount with ID=1) succeeded as before (repeated 5 times, no problem)
2) the next find (a WalletPlayerAccount with ID=2) succeeded as before (repeated 5 times, no problem)
3) the next find (the InternalPlayerAccount with ID=1 again) failed on the first attempt. (Actually, as explained previously, it doesn't *fail* but it returns an entity of type WalletPlayerAccount instead of InternalPlayerAccount.

Whilst in the debugger and immediately prior to step (3) above, I switched to a query tool and executed the SQL above to see if bad data was being returned (specifically whether nulls are returned for the InternalPlayerAccount columns), but everything looked good and valid data was returned from all three *Account tables.


In case it helps, here is the Hibernate log output. This first extract corresponds to step (1) in the list above, i.e. a successful find:



This second extract corresponds to step (3) in the list above, i.e. a find that returns an entity of the incorrect type.



The most interesting bits to my mind are the last two org.hibernate.engine.TwoPhaseLoad entries in each extract - in the first extract it resolves/materializes InternalPlayerAccount and in the second extract WalletPlayerAccount.

I'm going to continue investigating, but if this is ringing bells for anyone, I'd really appreciate any thoughts/comments/suggestions.

Darren


...followup post...


I think I'm getting somewhere... as I said previously, I'm reproducing the problem consistently by performing the following steps:

1) Finding an InternalPlayerAccount with ID=1 succeeds (repeated 5 times, no problem)
2) Finding a WalletPlayerAccount with ID=2 succeeds (repeated 5 times, no problem)
3) Finding the InternalPlayerAccount with ID=1 again returns an entity of type WalletPlayerAccount instead of InternalPlayerAccount on the first attempt.

and the actual logic looks something like this:


When I execute this, the code gets through the first inner loop all five times without a problem. It then gets through the second inner loop OK and starts to re-iterate the outer loop. It then fails on the first execution of findPlayerAccount(1).

So, I tried playing with the values of innerLoopLimit. If I increase it, the behaviour described above is always the same - first outer iteration succeeds, then the first iteration of the first inner loop fails.

However, if I decrease the innerLoopLimit to two, I find this isn't the case - loading the account with id=1 succeeds even on the second iteration of the outer loop until the 6th time in total, at which point it fails as before. I decrease the innerLoopLimit to one and see the same - I get 5 good finds of account with id=1 (even after loading a WalletPlayerAccount), then fail on the 6th.

This seemed fishy, I looked through my persistence.xml and noticed c3p0's connection pool min_size=5



I tried removing the c3p0-related properties from configuration altogether and my problem dissapears!


So, does anybody think this could be a C3P0 bug, or could it still be something I'm doing wrong (in which case all suggestions appreciated!)

Darren

what is the code for findPlayeAccount()?

In the cases I've described when the entity is returned properly as an InternalPlayerAccount, the code marked above with the [snip - some more Hibernate.initialize() calls] is executed. In later executions when the entity isn't returned correctly, that code is not executed as playerAccount instanceof InternalPlayerAccount returns false and the if-block is therefore not entered.


For completeness, called methods perform as follows (there is a fair amount of abstraction and nested methods involved to achieve what's described below so won't dump it all here unless you want me to)...

LgpCorePersistenceContextManager.getInstance() uses a ThreadLocal to return an instance of the LgpCorePersistenceContextManager class if the calling thread hasn't already done so, or returns the same on if the calling thread already has one.

LgpCorePersistenceContextManager.getReadOnlyEntityManager() returns the result of an EntityManagerFactory's createEntityManager().

LgpCorePersistenceContextManager.getQueryFindPlayerAccountWithPopulatedRelationships() returns a Query with populated parameters based on the following QL:

Code:
         SELECT DISTINCT pa
         FROM            PlayerAccount pa
         LEFT JOIN FETCH pa.accountSystem
         LEFT JOIN FETCH pa.preferredOutlet
         LEFT JOIN FETCH pa.notes
         WHERE           pa.id = :id

By the way, I'm confident that the logic for ThreadLocal-based session management is working OK.

If I trawl the logs, I find that every JDBC connection that gets opened is always closed, i.e. for every


there follows a



and for every


there follows a

I don't see any obvious reason, try to minimize your test case and use Hibernate APIs only, all the imbrications are hard to debug

I've replicated the problem in a standalone example with much of the irrelevant complexity removed.

I have three entities Animal, Cat and Lion, as follows:



The orm.xml and persistence.xml are straightforward:

ORM:


Persistence:



The code I execute to run the test is as follows:



So, I search for the animal with ID=1 (which is a Lion in the database) 5 times, then do the same for the animal with ID=2 (which is a Cat in the database). I then repeat the entire process.

If I run without C3P0 (i.e. comment out all c3p0-related settings in persistence.xml) I have no problems and my output looks like this:



I.e. the animal with ID=1 is always a Lion.

If I enable c3p0 (i.e. uncomment the settings in persistence.xml) then I get the same error previously described and the output looks like this:



So, as before, my Lions load as Lions until I've loaded some animals that are only Cats. From that point on, my Lions are also loaded as Cats, even though nothing has changed in the DB. Comment out the C3P0 settings at this point and everything works again.

I can post the actual files somewhere (i.e. java and xml) if that would help.

Thanks
Darren

you must use find() with the exact class type.
If you don't know the type, then you'll have to use a query

As I don't the type in advance, I've replaced the find() with a query, but get exactly the same results.

FYI, the code now reads



and the query is defined in the ORM as:

Then I'm short of explanation :)

Any ideas where I could go next, or what I could do to help get this diagnosed/fixed?

Thanks,
Darren

I tried tracing through the C3P0 code to see if there was something obvious, but nothing jumped out - I've posted an issue in SourceForge on the C3P0 project to see if problem is of interest over there.

A bit of a breakthrough today though - I tried changing the inheritance strategy to SINGLE_TABLE to see if that makes a difference and the problem goes away. I.e. in my ORM, I changed this:


to this



So the bug is particular to the JOINED inheritance strategy.