Forums

by Eric Peachey >> Mon, 6 Sep 1999 1:23:26 GMT

Hello,

An interesting new feature of JADE 5 is that should an exception occur whilst doing an automatic update, JADE aborts the transaction before control is passed back to your excetpion handler. This quite different to the behavoiur of JADE in previous releases - the online help doesn't seem to have caught up yet.

The new behaviour means that code that used to handle such exceptions (e.g. say a duplicate key when loading data from a file) may not work anymore. It may also mean that if you created say 100 objects per transaction and the exception is detected on the last one then all the previous objects will be rolled out. So, this means we're back to doing stuff like 'if myCollection.includesKey( something.key ) = false then create object....', instead of being able to handle the exception ourselves.

I understand that this behaviour was changed because developers weren't handling things correctly so the inverses between objects was not set properly. (This is third hand so don't take it as gospel.)

What do you others think?

Eric in Dunedin

by Wilfred Verkley >> Mon, 6 Sep 1999 3:31:50 GMT

I heard the problem was developers resuming the exception, thus causing the database to be corrupted with an inverse not properly matched.

The effect of this change means you cannot now put exeption handling on objects you are creating in the transaction.

Our jade 4 code often did this.

setKeyValue (value: KeyValue) updating;begin

on Exception do handleException (exception);
fMyKeyValue := value;
end;

Now in Jade 5, the object is destroyed before the exception handler is called (by the rollback), and then jade tries to call the exception handler on a non-existent object, causing more exceptions over and over.

I think aborting the transaction is a rather drastic thing to do. Couldnt the database prevent the user from setting the invalid key value instead?

Wilfred.

by Craig Shearer >> Mon, 6 Sep 1999 4:25:46 GMT

Further to Wilfred's post... this is in fact correct. JADE 5.0 now automatically aborts any exception that is encountered during automatic key maintenance to prevent developers from resuming through such exceptions and thus "corrupting" the database.

This issue has been raised with the plant, and they a working on a patch that would cause the transaction to be aborted at the end of the exception handling, rather than first up. This then allows you to handle the exception gracefully... however, it doesn't help with the situation where you have multiple objects to create.

Craig.

by Dean Cooper >> Mon, 6 Sep 1999 5:25:44 GMT

I heard the problem was developers resuming the exception, thus causing the database to be corrupted with an inverse not
properly matched.

Correct.

Now in Jade 5, the object is destroyed before the exception handler is called (by the rollback), and then jade tries to call the exception handler on a non-existent object, causing more exceptions
over and over.

From 5.0.13, the transaction is aborted *on return* from the first exception handler, which means that any creates and/or updates will still be visible to you in your exception handler.

I think aborting the transaction is a rather drastic thing to do. Couldnt the database prevent the user from setting the
invalid key value instead?

The database is preventing the dictionary update by raising the exception. The problem is that one side of the relationship has already been updated. One option we did consider was a validate phase for automatic updates that would "try" the entire operation and not even apply the manual update unless this succeeded (sort of like a two-phase update); on the surface this isn't a bad idea. Another approach (not available right now as it assumes the existence of nested transactions) would be to bracket each automatic update in its own sub-transaction. However, both of these options would introduce significant overhead to inverse and dictionary key maintenance that would penalise *every* automatic update; with the benefits only being realised in those (hopefully) few cases that result in exceptions. We could not accept this performance impact. Aborting the transaction protects the integrity of your data without penalising every operation. In those cases where you do want to take some corrective action on an error (such as the batch example in Eric's post), you can check the operation up front in only those places that you require.

Dean.

by Dean Cooper >> Mon, 6 Sep 1999 4:33:42 GMT

An interesting new feature of JADE 5 is that should an exception occur whilst doing an automatic update, JADE aborts the transaction before control is passed back to your excetpion handler.

This has been changed. As a result of feedback from users, from 5.0.13 if an exception occurs during an automatic update (ie: inverse maintenance, automatic key maintenance, parent-child deletions), the kernel will abort the transaction *on return* from the first exception handler (currently the transaction is aborted before your exception handler is called). This means that you will still be in transaction state in your exception handler, and any objects created or updated in the transaction will still be visible. Any attempt to commit the current transaction in your exception handler will raise a 1252 exception (Transaction must be aborted). Of course, if you abort the current transaction yourself (often a very good idea), you are then free to begin and commit new transactions.

I understand that this behaviour was changed because developers weren't handling things correctly so the inverses between objects was not set properly. (This is third hand so don't take it as gospel.)

Correct. We have seen numerous problems caused by exception handlers simply resuming through exceptions and not aborting the transaction. If this is done during an automatic update, the transaction can then be allowed to commit; which often results in one side of a relationship being updated (the property or collection whose update initiated the automatic update), while the other side hasn't (because it encountered an exception). You're then left with logically corrupt inverses or dictionary keys. Too often this situation has been caused by generic, catch-all type exception handlers being armed during transactions for which more specific, context-aware handler(s) would have been more appropriate.

Dean.