I have a standalone Java server that is owner of replicated TreeCache data. The other member in the cluster is JBoss 4.0.4. Replication is working and use of the treecache mbean allows me to see the data in the treecache in JBoss. The standalone app has its cache usage set to transactional. The JBoss container is a read only cache that will be under high volume reads and must perform optimally.

According to the hibernate FAQ second level cache is for lookup by identifier only and is not used when data is looked up via SQL. The problem is the SQL that is being used is done behind the scenes by hibernate to populate association data and is therefore not using the second level cache. Is there a way to force hibernate to not use SQL and thus force it to use the second level cache when pulling the association data?

If we turn on the SQL cache then I fear that stale data will be cached. Updates replicating via tree cache will be ignored by the sql cache as these entities have no knowledge of each other. We cannot afford stale data as this system has a real time requirement. We also can't afford to hit the DB every time when we already have the data in memory.

I see 2 possible solutions but am hoping for some alternate ideas.

1) re-design our relationships and data access so that SQL is never used (this is cumbersome and undesirable).
2) Create (or obtain) a JDBC driver that will use the TreeCache as its underlying data store rather than going outside to our DB.

Does anyone see any alternate solutions that won't re-quire a major re-design? Does any JDBC driver already exist for TreeCache? Is there an enhancement to Hibernate that will solve this problem planned for the future?

Thanks in advance for any advice.

Jeff