Forums

by cdshearer >> Thu, 7 Mar 2002 1:36:16 GMT

Hello All

Here's a tip that I've come up with that may help...

When writing set methods that set properties that are keys, some developers test the value of the property before setting it, in order to avoid setting it if it's already that value.

For example:

setName(pName: String) updating;
begin

if name <> pName then
name := pName;
endif;
end;

The reasoning behind this is that, if the property is a key in a dictionary, then JADE will be forced to remove the object from the collection using the old key value and add the object into the collection again with the new key value. If the key value hadn't changed then JADE would have just updated the collection for no reason (and locked it, and used valuable processor time, I/Os and all that stuff!)

So, developers write code that tests the property first to avoid setting it if it hasn't changed.

The problem with this is that if the object hasn't been previously locked then the code could inspect a stale copy of the object in cache and thus incorrectly conclude that the property was already set to the value when in fact it wasn't. This is because the object won't be locked (unless explicitly locked previously) until it is updated. Admittedly, for this scenario to be true, the value would have had to have been that value at some previous time (but stange things happening in computer systems...)

There are three ways around this:

1. Ensure that you lock the object before calling any set methods.
2. Code it as follows:

setName(pName: String) updating;
begin

exclusiveLock(self);
if name <> pName then
name := pName;
endif;
end;

3. Use the lockReceiver modifier on the method:

setName(pName: String) updating, lockReceiver;
begin

if name <> pName then
name := pName;
endif;
end;

Approach 1 is error prone as the code relies on somebody else to lock the object first, and could possibly fail if the object wasn't locked. Approach 2 is ok, but approach 3 is better.

Using the lockReceiver modifier causes JADE to exclusively lock the object as soon as it enters the method.

With the 3rd approach, it performs better as there is one less statement to be executed. Also, it's better because it's declarative rather than programmatic.

Comments?

Craig

by cdshearer >> Thu, 7 Mar 2002 1:45:54 GMT

An interesting addendum to this is that the JADE documentation describes the lockReceiver tag as only working on Collection subclass methods... but it works on any class. I guess the documentation is wrong