Instance Volatility

[ConvertFromOldNGs]

by Jimmy Menzies >> Thu, 5 Jul 2007 2:01:49 GMT

I am just in the process of upgrade a Jade 6.0 environment to 6.1 and have a question regarding this. The description in the JADE documentation leaves some room for ambiguity.

Does volatility refer to all instance updates or just changes to existing instances? I.e. If instances of a class were created frequently but NEVER changed or deleted once created would that be considered volatile or frozen?

[ConvertFromOldNGs]

by Allistar >> Thu, 5 Jul 2007 2:08:55 GMT

From what I'm aware instance volatility is a mechanism to help the object manager make more intelligent decisions when it comes to object locking. From that perspective, it only refers to instance changing.

Volatility can be applied as a default at the class level or at an instance level (so you can have some instances of a class as frozen while others are not).

Freezing an instance is handy when it comes to collections that never change, as the normal locking semantics don't need to take place, improving efficiency.

Allistar.

[ConvertFromOldNGs]

by cnwjhp1 >> Thu, 5 Jul 2007 3:53:15 GMT

Making collections Stable can help reduce locking overheads. Functions such as Collection::getAtKey, Iterator::next etc share lock the collection for the duration of the function. The collection doesn't stay locked for long, but it is two trips to the database server to lock and unlock it. If a collection doesn't change much, those trips can be avoided.

[ConvertFromOldNGs]

by Jimmy Menzies >> Fri, 6 Jul 2007 0:50:14 GMT

So in my case the collection would be 'volatile' but the instances of that collection 'frozen'?

[ConvertFromOldNGs]

by cnwjhp1 >> Fri, 6 Jul 2007 1:52:13 GMT

Presumably when you say 'instances of that collection', you mean the member objects the collection is pointing to. It is only of benefit to declare them stable or frozen if they are locked a lot without being updated. If you are not aware of that being the case (it would be unusual if it were the case), you should probably leave them 'volatile', as they were in 6.0.

If you retrieve frequently from the collection, but do not add or remove from it frequently, there may be a benefit from declaring it 'stable'.

[ConvertFromOldNGs]

by Allistar >> Sun, 8 Jul 2007 22:29:51 GMT

So in my case the collection would be 'volatile' but the instances of that collection 'frozen'?

Presumable the instances are added to the collection during inverse maintenance, in which case when the collectino is updated the particular instance being added or removed from the collection will be updated too.

I would make a collection frozen if it is populated once at system initialisation time and then never added to or removed from during normal operation. This is especially true if you read from this collection a lot (e.g. display it in a combobox or otherwise iterate through it).

If you do want to update the collection, make it volatile again. If the updating only happens in single user mode (such as during deployment or upgrades) then there is little expense in changing the volatility of the collection (by definition there are no other nodes with a "node level" lock on the collection).

Allistar.