Does Hibernate query objects in memory in addition to the database?

[david.karr]

I'm using Hibernate 3.0.5, JDK 1.4.2, and WebLogic 8.1.4.

I discovered something odd in how a Hibernate query was behaving.

From what I can tell, the behavior makes me think that when a

Hibernate query executes, it doesn't just query the database, but it
also queries any existing mapped objects in memory, which have not
been created in the database yet.

Before I started my test case, I used SQLDeveloper to verify that my
particular table was empty. My test case code first "new"s a bunch of
objects that are mapped to this table through Hibernate, but I only
put each one of them into a list. After that loop, I executed a
Hibernate query on that table, in order to delete the rows that it
finds. Surprisingly, the query didn't return 0 rows. It appeared to
return results for the objects that I had just created, but had not
persisted. After that code, it's supposed to persist those "new"ed
objects into the database. Unfortunately, in my test case, it never
gets there, because the transaction times out after executing the
"delete" statements for the allegedly existing rows.

I then rearranged my code so that the query for delete runs first, and
then it goes through the loop that "new"s the objects and then later
persists those. With the code in this order, it works fine.

Is this along the lines of expected behavior? I'm still trying to
understand the ramifications of this.

 

[Adam Maass]

I'm using Hibernate 3.0.5, JDK 1.4.2, and WebLogic 8.1.4.

I discovered something odd in how a Hibernate query was behaving.
Hibernate query executes, it doesn't just query the database, but it
also queries any existing mapped objects in memory, which have not
been created in the database yet.

Before I started my test case, I used SQLDeveloper to verify that my
particular table was empty. My test case code first "new"s a bunch of
objects that are mapped to this table through Hibernate, but I only
put each one of them into a list. After that loop, I executed a
Hibernate query on that table, in order to delete the rows that it
finds. Surprisingly, the query didn't return 0 rows. It appeared to
return results for the objects that I had just created, but had not
persisted. After that code, it's supposed to persist those "new"ed
objects into the database. Unfortunately, in my test case, it never
gets there, because the transaction times out after executing the
"delete" statements for the allegedly existing rows.

I then rearranged my code so that the query for delete runs first, and
then it goes through the loop that "new"s the objects and then later
persists those. With the code in this order, it works fine.

Is this along the lines of expected behavior? I'm still trying to
understand the ramifications of this.

A simple "new" should not have resulted in the new objects being returned by
the query. However, new objects that have been through a session.save() (or
likewise) should have. Before Hibernate runs a query, it flushes (but does
not commit) all pending changes to the database; the database should query
inserted or updated records just like it queries records that have not been
written to yet in this transaction. This way, queries run on the current
state of the objects, even if that state has been modified in the current
session.

Hmmm -- an "insert" followed by a "delete" should be legal on the same row
in the same transaction, but from the sounds of it, is not what you were
expecting.