Hello all!

First, let me give a quick rundown on the software set up that I am using:
- App Server: Jboss 4.2.2.GA
- Hibernate 3
- Spring
- Java 1.5 / 1.6
- Eclipse IDE
- Appserver resides on a Solaris 10 machine

I am fairly new with Hibernate myself, but I have been working on a project for quite some time that a number of people had been working on before I started. The application itself is fairly complex, with a number of Hibernate mappings for a large number of the tables in our database. We have Hibernate's second_level_cache enabled, as there is a large amount of traffic using our application.

Hibernate's cache had been working fine for us for quite awhile. In each of our mapping files, we have an explicit statement of the cache region that we're using, as well as a usage of "nonstrict-read-write". All has been well. We could use the application, and Hibernate would do it's work without an issue. I could check the log file, and it would verify that the second level cache was set up properly:



I then began doing some stuff that required me to update to Java 6 (1.6). After upgrading to Java 6, I could build and deploy my application using Java 6. Since it was being compiled with Java 6, I had to upgrade to Java 6 on my deployment machine as well. However, this is where the problem begins.

I first noticed there was an issue when I tried accessing a part of my application that required modifying the database. I immediately got an error stating:



After much fudging around, I discovered that when deploying JBoss with Java 6, the log file instead stated:



Therein lies the rub. Rather than the second_level_cache being nonstrict-read-write, it is now read-only! However, the ONLY thing that has been changed between the two deployments is updating from Java 5 to Java 6. I verified this by reverting back to Java 5, and the application deployed without a problem. I deployed the exact same built EAR file both times. With Java 5, it worked as nonstrict-read-write. With Java 6, it didn't work as read-only.

I then disabled Hibernate's second_level_cache and attempted to run the application through JBoss on Java 6 again. Lo' and behild, it still worked. So, it appears that the root cause of the entire thing is the Hibernate OSCache region being set to ReadOnly via Java 6.

I've looked everywhere, and I haven't come across a solution to fix this problem yet. Obviously I could leave the environment in Java 5, but I would much rather stay as up-to-date as I can. As stated, each of my Hibernate mapping files have "nonstrict-read-write" usages. However, I haven't found a spot to directly set the cache region as "nonstrict-read-write". I'm assuming by default it's set somewhere in the Hibernate3.jar. But, what I don't understand is why it changes when I update to Java 6, when everything else in the environment stays the same.

Can someone please shed some light on this issue for me? I've tried doing quite a bit of searching (I've been at this issue for a few days now), but it doesn't seem like anybody else has come across this issue. As stated, I'm a relative "n00b" with Hibernate, so I very easily could be overlooking a simple solution for the problem.

Is there some easy fix/patch for this? Or does this problem go much deeper than just a Java update?

Thanks for all the help you can give!

Just as an update:

After doing a bunch more testing, it seems that I am unable to use the same cache region as both read-only and nonstrict-read-write. I still notice the problem, where when I'm compiling using Java 5, it builds the cache region as nonstrict-read-write, whereas Java 6 builds it as read-only.

But, through our application, we have multiple mappings that we have set to use the same cache region - some of which use it as read-only, and some of which use it as nonstrict-read-write. By changing all of the mappings to be nonstrict-read-write, when I compiled with Java 6, it built it as nonstrict-read-write. Thus, it seems that I am unable to build the cache for multiple kinds of usage.

I then in turn created two cache regions - one that I specified when I was declaring "read-only" usage, and one that I called when I was using "nonstrict-read-write" usage. Upon deploying the application, it set up both regions, and their usages, as expected.

So, I guess as a solution, I can build two distinct cache regions - one for read-only, and one for nonstrict-read-write. I don't know if there's any performance difference between having two regions, and having one region set for both types of use.

For now I will just continue with both usage types, and hopefully someone will respond and shed some light on this situation to explain as to why it's acting in this fashion. I can't be the first one to have come across this issue, can I?

Any info is appreciated!

Anybody have any ideas?

Hi steve,
Is that problem resolved? I am also facing a similar kind of problem.