Hibernate version:
Hibernate 3.0.5
Mapping documents:
work fine
Code between sessionFactory.openSession() and session.close():
works fine
Full stack trace of any exception that occurs:
n/a
Name and version of the database you are using:
MYSQL Server version 4.1.10a-standard

Hi there,

when I an Object using 1 of 2 different configured hibernate SessionFactories the changes made one factory's session are not visible by sessions created by the other factory.
The Database state of the modified object has in fact changed.
Some kind of cache interferes?!

I need different SessionFactories because they have a slightly different configuation (batch vs. frontend).

IMHO my problem is NOT caused by the 1st Level cache because -for the frontend- I close and open the session for every Http-Request.
To my understanding a flush() is called when closing the session and the 1st level cache's state is refreshed from the DB when opening a new Session.

IMHO my problem is neither caused by the 2nd level cache.
For testing reasons I have disabled the 2nd level cache in both 2 SessionFactories by
adding this to my session manager:
factory = new Configuration().configure().setProperty("hibernate.cache.use_second_level_cache", "false").buildSessionFactory();
In fact no 2nd level cache activity is being logged.

I don't store objects in the Http Session or elsewhere.

Regretfully I must say I am out of Ideas. Where should I look at, what should I read about?
Do you need more Info, please ask.

Thanks
Kai

"the changes made one factory's session are not visible by sessions created by the other factory. "

this is the expected behavior ;)

Let me explain better:

the database's state has changed because the background process batch-updated some values.
the changes are visible directly in the DB but the frontend process still shows the old values although the session has been flushed.

IMHO the expected behavior should be not to present stale data.
How can I achieve this?

Any hints?
Dennis, if you have any links describing this behavior please post.

Thanks
Kai

if you have staleness problems, take a look at at section 4.4 regarding the different way you can disable caching ... and what happens if you call Session.clear() ?

http://www.hibernate.org/hib_docs/v3/re ... ation.html

Thanks for the Answer. I tried to Session.clear() and disabled also the last remaining 2nd level cache activity 'QueryCache' as I have read in the docu.
But still my frontend sees stale data.

I still have no clue where the objects may be cached. As can be seen in the appended log the 2nd Level Cache is inactive.
With Session.clear() I guess also the 1st Level cache is cleared.

Any Ideas?

Thanks
Kai
-----------------

This is the config protocol of my frontend's Factory:

21:02:34,336 [ INFO] [ManagerConnectionProvider] : 41 - Using Hibernate built-in connection pool (not for production use!)
21:02:34,336 [ INFO] [ManagerConnectionProvider] : 42 - Hibernate connection pool size: 20
21:02:34,337 [ INFO] [ManagerConnectionProvider] : 45 - autocommit mode: false
21:02:34,338 [ INFO] [ManagerConnectionProvider] : 80 - using driver: com.mysql.jdbc.Driver at URL: jdbc:mysql://localhost:3306/planets
21:02:34,339 [ INFO] [ManagerConnectionProvider] : 83 - connection properties:
21:02:34,339 [DEBUG] [ManagerConnectionProvider] : 93 - total checked-out connections: 0
21:02:34,340 [DEBUG] [ManagerConnectionProvider] : 109 - opening new JDBC connection
21:02:34,359 [DEBUG] [ManagerConnectionProvider] : 115 - created connection to: jdbc:mysql://localhost:3306/planets, Isolation Level: 4
21:02:34,361 [ INFO] [rnate.cfg.SettingsFactory] : 77 - RDBMS: MySQL, version: 4.1.10a-standard
21:02:34,361 [ INFO] [rnate.cfg.SettingsFactory] : 78 - JDBC driver: MySQL-AB JDBC Driver, version: mysql-connector-java-3.1.10 ( $Date: 2005/05/19 15:52:23 $, $Revision: 1.1.2.2 $ )
21:02:34,364 [DEBUG] [ManagerConnectionProvider] : 129 - returning connection to pool, pool size: 1
21:02:34,393 [ INFO] [hibernate.dialect.Dialect] : 92 - Using dialect: org.hibernate.dialect.MySQLInnoDBDialect
21:02:34,399 [ INFO] [TransactionFactoryFactory] : 31 - Using default transaction strategy (direct JDBC transactions)
21:02:34,404 [ INFO] [ctionManagerLookupFactory] : 33 - No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
21:02:34,405 [ INFO] [rnate.cfg.SettingsFactory] : 125 - Automatic flush during beforeCompletion(): disabled
21:02:34,405 [ INFO] [rnate.cfg.SettingsFactory] : 129 - Automatic session close at end of transaction: disabled
21:02:34,406 [ INFO] [rnate.cfg.SettingsFactory] : 136 - JDBC batch size: 15
21:02:34,406 [ INFO] [rnate.cfg.SettingsFactory] : 139 - JDBC batch updates for versioned data: disabled
21:02:34,407 [ INFO] [rnate.cfg.SettingsFactory] : 144 - Scrollable result sets: enabled
21:02:34,407 [DEBUG] [rnate.cfg.SettingsFactory] : 148 - Wrap result sets: disabled
21:02:34,408 [ INFO] [rnate.cfg.SettingsFactory] : 152 - JDBC3 getGeneratedKeys(): enabled
21:02:34,408 [ INFO] [rnate.cfg.SettingsFactory] : 160 - Connection release mode: null
21:02:34,409 [ INFO] [rnate.cfg.SettingsFactory] : 184 - Maximum outer join fetch depth: 2
21:02:34,409 [ INFO] [rnate.cfg.SettingsFactory] : 187 - Default batch fetch size: 1
21:02:34,410 [ INFO] [rnate.cfg.SettingsFactory] : 191 - Generate SQL with comments: disabled
21:02:34,410 [ INFO] [rnate.cfg.SettingsFactory] : 195 - Order SQL updates by primary key: disabled
21:02:34,410 [ INFO] [rnate.cfg.SettingsFactory] : 334 - Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
21:02:34,413 [ INFO] [ASTQueryTranslatorFactory] : 21 - Using ASTQueryTranslatorFactory
21:02:34,414 [ INFO] [rnate.cfg.SettingsFactory] : 203 - Query language substitutions: {true=1, false=0}
21:02:34,414 [ INFO] [rnate.cfg.SettingsFactory] : 209 - Second-level cache: disabled
21:02:34,414 [ INFO] [rnate.cfg.SettingsFactory] : 213 - Query cache: disabled
21:02:34,418 [ INFO] [rnate.cfg.SettingsFactory] : 228 - Optimize cache for minimal puts: disabled
21:02:34,419 [ INFO] [rnate.cfg.SettingsFactory] : 237 - Structured second-level cache entries: disabled
21:02:34,420 [DEBUG] [ExceptionConverterFactory] : 52 - Using dialect defined converter
21:02:34,426 [ INFO] [rnate.cfg.SettingsFactory] : 261 - Statistics: disabled
21:02:34,426 [ INFO] [rnate.cfg.SettingsFactory] : 265 - Deleted entity synthetic identifier rollback: disabled
21:02:34,427 [ INFO] [rnate.cfg.SettingsFactory] : 279 - Default entity-mode: pojo
21:02:34,549 [ INFO] [e.impl.SessionFactoryImpl] : 152 - building session factory

make sure this isn't pushing the older object state of your front end process back into the database, over the batch updates - ;-)

thanks Dennis, this is really a risk.

I am now adjusting my classes to enable the batch processes to use the same jvm and the same Session factory although that creates an ugly dependency between the batch processes and the Web frontend.
Maybe this issue would be worth writing a few lines in the docu under '14 batch processing', like the hibernate project has documented so many other common problems.

Gruss
Kai

Do you have another solution right now than to take the same session, because I have exactly the same problem???

Thx
Markus

commit transaction before to reread data.