We do the following:

We have a class VAT mapped with <cache usage="read-only"/>.

In a setup program using NHibernate, we do (about) the following:

VAT v = new VAT();
v.Percentage = 19.0;
v.Name = "Full VAT";
session.Save(v);

This works.

In a test case, someone wrote:

VAT v = new VAT();
session.Save(v);
v.Percentage = 19.0;
v.Name = "Full VAT";
...flush+commit follows much later...

This leads to an InvalidOperationException "Can't write to a readonly object" from the class ReadonlyCache's Lock method.

The behavior stems from the fact that NHibernate (and, AFAIK, Hibernate) creates a new object in a somewhat roundabout way: It remembers the object exactly at the point of the Save(); and then does a compare when it flushes the new object. From these, it emits an INSERT and an UPDATE.

---> If this behavior is stable (you *can* create a new object with a *readonly-cache* if you take care that no changes are done after Save()) and will be supported for all future, we are happy and will use this idiom.

---> If not, how should a program work that wants to insert objects for a class marked with <cache usage="read-only"/>?

Regards
Harald M.

Yes, you can consider this behavior stable.