When using read/write strategy are the objects(business objects/entity objects) cached in the session factory? In the code below it does not seem to use the cache and hits the DB each time the code tries to load it from a new session. So does that mean that if you use read/write strategy no second level caching is provided?

Note:
1. if i use read-only & nonstrict-read-write the caching seems to work and does not hit the DB on subsequent loads.
2. I went through the documents, forum and was not able to get enough information to understand why it was not caching in read/write strategy.
3. i do not want to cache the query, i want to cache the objects that are already loaded to reduce the db hits.

mapping file :



code:



I am using net.sf.ehcache.hibernate.Provider

Why not enable logging for net.sf.hibernate.cache.* and see whats going on?

In frist session


In the next session


Looks like it is caching and also accessing from cache. But it does hit the db also(issues a hiberanate query to hit the db).

Well, thats because it was locked, as the log says. Try using Transactions as documented.

well I am using transcation as recommended. And using LockMode.NONE when loading the object. And i am just loading the object in both the session, no updates are done in this example.

session = sessionFactory.openSession();
transaction = session.beginTransaction();
Object obj1 = session.load(....)
transaction.commit();
session.close();

I also stepped through hibernate second level caching. I am not sure but the obersvation could be a potential bug.

1. When a object is loaded for the first time(read-write strategy) ReadWriteCache.Item is cached with the object we try to load and curent timestamp(System.currentTimeMillis()).

2. when the object is subsequently loaded(in a different transcation), the method call lockable.isGettable(txTimestamp)(line 75 ReadWriteCache) always passes Long.minValue(-9223.......). And the method isGettable(..) compares the Long.minValue & previously cached timestamp and will always return false. Hence we get the log message "Cached item was locked"....

It still must be your fault, because this works just fine if used correctly.

If i use openSession() to get a Session my code works fine. (caching works fine).

But in the case i posted before i am calling
openSession(Connection connection, Interceptor interceptor)

SessionFactoryImpl sets timestamp to Long.minValue if openSession(Connection connection, Interceptor interceptor) (line 316) is called

SessionFactoryImpl sets timestamp to settings.getCacheProvider().nextTimestamp() value if openSession() (line 316) is called

Is there any setting i have to change to get the caching working in my case?

I really appreciate the prompt replies.

Caching will be turned off if you supply your own JDBC connection. Hibernate can't know what else you might have done on this connection, hence you would run get stale data problems.

In a way it is the connection got from Hibernate(not a self created jdbc connection). The code actually gets the connection from ConnectionProvider and passes it on to the openSession(....) method. Once the session is closed the connection is returned to the pool. Is that not good enough to use the caching facility?

No. It's really simple: if you call openSession(yourConnection), Hibernate assumes that you have been executing SQL on this connection and that the current database transaction (which is in this case also your responsibility) can not be trusted for the second-level cache. There is no workaround. Let Hibernate manage the connection if you want the second-level cache. You can of course call session.connection() once it is open, do some SQL/JDBC, and then continue. It is then your responsibility to evict() the SessionFactory/second-level cache appropriately if you modified data.

got it. Thanks for being patient and really appreciate the help provided.

Due to certain design choices and patterns we use it becomes very necessary to use openSession(connection...), but at the same time we neither perform any SQL/JDBC operation with the jdbc connection nor open any transcation hence in this particular case the connection can be trusted.

Is it possible to have this choice of trust as configurable or to be left to the user?

e.g. by providing a method like

openSession(Connection c, Interceptor i, boolean trustedConnection)
openSession(Connection c, boolean trustedConnection)

No, better implement your own ConnectionProvider.

We have subclassed the ConnectionProvider to give our implementation, but i cannot understand how this will change the caching choice.

Did you try it or do you want to keep me busy guessing?